Network Working Group A. Conta Request for Comments: 3122 Transwitch Corporation Category: Standards Track June 2001
Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
Расширения IPv6 ND для реверсного обнаружения
Статус документа
В этом документе приведена спецификация проекта стандартного протокола Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущий статус стандартизации протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.
Авторские права
Copyright (C) The Internet Society (2001). Все права защищены.
Аннотация
Этот документ описывает расширение IPv6 Neighbor Discovery, позволяющее узлу определить и анонсировать адрес IPv6, соответствующий данному адресу канального уровня. Эти расширения названы реверсным обнаружением соседей (Inverse Neighbor Discovery или IND). Протокол IND был разработан для сетей Frame Relay, но может применяться в других сетях с походим поведением.
Оглавление
Исключено в варианте HTML
1. Введение
Этот документ определяет расширение протокола обнаружения соседей IPv6 (Neighbor Discovery или ND) [IPv6-IND], названное реверсным обнаружением соседей IPv6 (Inverse Neighbor Discovery или IND). IND позволяет узлу по адресу канального уровня подключённого напрямую узла узнать его адрес IPv6. Узел, применяющий IND, передаёт запросы и получает анонсы для одного или нескольких адресов IPv6, соответствующих заданному адресу канального уровня.
Протокол IND разработан для сетей Frame Relay, но применим и в других сетях с похожим поведением.
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии [KEYWORDS].
Имеется много сходств и различий между описанными здесь механизмами и механизмами протокола Inverse ARP для IPv4 [INV-ARP] или заменяющих его документах.
2. Сообщения IND
2.1. IND Solicitation
Узел передаёт сообщение IND Solicitation для запроса адреса IPv6, соответствующего адресу канального уровня целевого узла, а также для указания тому своего адреса на канальном уровне. Поскольку адрес IPv6 удалённого узла неизвестен, IND Solicitation передаётся по групповому адресу IPv6 all-nodes [IPv6], [IPv6-FR], [ENCAPS], однако на канальном уровне IND Solicitation передаётся целевому узлу напрямую по адресу канального уровня.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-
Поля IP
Source Address
Адрес IPv6 передающего сообщение интерфейса.
Destination Address
Групповой адрес IPv6 all-nodes, указываемый со областью действия на канале, т. е. FF02::1.
Hop Limit
255
Authentication Header
При наличии защищённой связи (Security Association или SA) для IP AH между отправителем и получателем отправителю следует включать этот заголовок.
Поля ICMP
Type
141
Code
0
Checksum
Контрольная сумма ICMP, см. [ICMPv6].
Reserved
Неиспользуемое поле, в котором отправитель должен указывать 0, а получатель должен игнорировать поле.
Требуемые опции
Отправитель должен указать приведённые ниже опции в сообщении Solicitation.
Source Link-Layer Address
Адрес отправителя на канальном уровне.
Target Link-Layer Address
Адрес целевого узла на канальном уровне.
Другие действительные опции
Отправитель может указать в сообщении Solicitation перечисленные ниже опции.
Source Address List
Список из одного или нескольких адресов IPv6 для интерфейса, указанного полем Source Link-Layer Address. Опция определена в разделе 3.
MTU
Настроенное для канала значение MTU [IPv6-ND].
В будущих версиях протокола могут появиться новые опции. Получатели должны игнорировать неизвестные опции, продолжая обработку сообщения.
2.2. IND Advertisement
Узел передаёт анонсы IND Advertisement в ответ на запрос IND Solicitation.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-
Поля IP
Source Address
Адрес IPv6 передающего сообщение интерфейса.
Destination Address
Значение Source Address из вызвавшего отклик сообщения IDN Solicitation.
Hop Limit
255
Authentication Header
При наличии защищённой связи (Security Association или SA) для IP AH между отправителем и получателем отправителю следует включать этот заголовок.
Поля ICMP
Type
142
Code
0
Checksum
Контрольная сумма ICMP, см. [ICMPv6].
Reserved
Неиспользуемое 32-битовое поле, в котором отправитель должен указывать 0, а получатель должен игнорировать поле.
Требуемые опции
Отправитель должен указать приведённые ниже опции в сообщении Advertisement.
Source Link-Layer Address
Адрес отправителя IND Advertisement на канальном уровне.
Target Link-Layer Address
Адрес на канальном уровне узла, который который передал запрос IND Solicitation.
Target Address List
Список из одного или нескольких адресов IPv6 для интерфейса, указанного полем Target Link-Layer Address в сообщении IND Solicitation, вызвавшем анонс. Опция определена в разделе 3.
Другие действительные опции
Отправитель может указать в сообщении Advertisement указанную ниже опцию.
MTU
Настроенное для канала значение MTU [IPv6-ND].
В будущих версиях протокола могут появиться новые опции. Получатели должны игнорировать неизвестные опции, продолжая обработку сообщения.
3. Формат опций IND
Сообщения IND включают опции ND [IPv6-ND], а также свои опции Source Address List и Target Address List.
3.1 Списки адресов
Опции Source Address List и Target Address List используют формат TLV (тип, размер, значение, см. параграф 4.6 в [IPv6-ND] с показанными на рисунке полями.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - + | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ | +-+-+-+-+...
Type
9 для Source Address List;
10 для Target Address List.
Примечание. Значения Option Type следует назначать из семейства IPv6 ND.
Length
Размер опции (включая поля Type, Length, Reserved) в 8-октетных блоках. Минимальное значение Length составляет 3 (один адрес IPv6).
Reserved
Неиспользуемое поле, в котором отправитель должен указывать 0, а получатель должен игнорировать поле.
IPv6 Addresses
Один или несколько адресов IPv6 для интерфейса.
Source Address List содержит список адресов IPv6 для интерфейса, указанного полем Source Link-Layer Address, Target Address List – для интерфейса, указанного Target Link-Layer Address. Число адресов в списке (n) определяется по размеру опции как
n = (Length - 1)/2
Поле Source Address List должно помещаться в одно сообщение IND Solicitation, поэтому список может быть неполным. Для полного списка адресов IPv6 узлу следует полагаться на сообщение IND Advertisement.
В поле Target Address List следует указывать полный список адресов интерфейса, указанного полем Target Link-Layer Address. Если список не помещается в одно сообщение IND Advertisement, после него следует передать ещё 1 или несколько анонсов IND Advertisement с теми же полями. В опцию Target Address List второго и последующих анонсов следует включать продолжение списка адресов IPv6 для интерфейса, указанного Target Link-Layer Address, которые не поместились в предыдущий анонс.
Примечание 1. Действие механизма IND ограничено обнаружением адресов IPv6, т. е. предоставлением сведений о сопоставлении адресов. Поэтому протокол не содержит положений и правил использования узлом адресов, возвращённых в сообщении IND. Более того, из списков протокол не исключает каких-либо типов адресов IPv6. Например, при наличии адресов, заданных вручную и автоматически, включая временные, индивидуальные, групповые и т. п., из списка не следует исключать ни одного адреса.
Примечание 2. Реализации недопустимо передавать в списке дубликаты адресов IPv6.
4. Протокол IND
Работа IND очень похожа на ND [IPv6-ND] – запрашивающий целевой адрес IP узел передаёт запрос через свой интерфейс, целевой узел отвечает анонсом с требуемыми сведениями. Полученная информация может быть сохранена в кэше ND [IPv6-ND] или адресных структурах IPv6, которые могут быть связаны с интерфейсом.
4.1. Обработка на передающем узле
Запрашивающий узел форматирует сообщение IND Solicitation, как указано в параграфе 2.1, инкапсулирует пакет для канального уровня и передаёт его напрямую целевому узлу. Хотя в качестве IP-адреса получателя указан групповой адрес all-nodes, сообщение передаётся лишь целевому узлу. Значимыми полями для протокола IND являются Source Address, Source Link-Layer Address, Target Link-Layer Address и MTU. Последнее поле может служить для установки оптимального значения MTU на канале.
В ожидании отклика отправителю следует повторять сообщение IND Solicitation с интервалом приблизительно RetransTimer (по завершении отсчёта) [IPv6-ND] даже при отсутствии другого трафика к соседу. Повторы должны ограничиваться по скорости – не более одного для соседа в каждом интервале RetransTimer.
Отсутствие ответа IND Advertisement после отправки MAX_MULTICAST_SOLICIT [IPv6-ND] запросов считается отказом. Если отправка Solicitation требовалась вышележащим уровнем, модуль отправителя должен уведомить вышележащий уровень об ошибке, используя подходящий механизм (например, код завершения процедуры).
4.2. Обработка на приёмном узле
4.2.1. Обработка IND Solicitation
Для каждого IND Solicitation принявшему запрос узлу следует создать подходящий отклик IND Advertisement, используя адреса отправителя и цели на канальном уровне, а также адрес отправителя IPv6 из IND Solicitation.
Если узел обновляет кэш ND с использованием сведений из сообщений IND, получателю IND Solicitation следует поместить адреса отправитель (IPv6 и канальный) в свой кэш ND [IPv6-ND] как для запросов ND.
Поскольку узлы IPv6 могут иметь несколько адресов IPv6 на интерфейсе, отвечающему на IND Solicitation узлу следует возвращать в опции Target Address List список адресов IPv6, соответствующих интерфейсу, указанному полем Target Link-Layer Address в запросе. Список должен не иметь дубликатов адресов.
4.2.2. Обработка IND Advertisement
Если узел обновляет кэш ND сведениями из сообщений IND, получателю IND Advertisement следует поместить адреса отправителя (IPv6 из опции Target Addresses List и канальный) из анонса IND Advertisement в свой кэш ND [IPv6-ND] как для анонсов ND.
4.3. Проверка сообщений
4.3.1. Проверка IND Solicitation
Узел должен отбрасывать без уведомления отправителя любые сообщения IND Solicitation, для которых не выполняются все приведённые ниже условия.
-
Поле IP Hop Limit имеет значение 255, т. е. пакет не передавался через маршрутизаторы.
-
При наличии заголовка IP AH аутентификация прошла успешно.
-
Значение ICMP Checksum действительно.
-
ICMP Code = 0.
-
Размер ICMP (выводится из размера IP) не менее 24 октетов.
-
Должна присутствовать обязательная опция Target Link-Layer Address.
-
Должна присутствовать обязательная опция Source Link-Layer Address.
-
Все включённые опции имеют размер больше 0.
Содержимое поля Reserved и любые нераспознанные опции должны игнорироваться. Будущие изменения протокола, совместимые с прежними версиями, могут задавать содержимое поля Reserved и добавлять опции, несовместимые изменения могут задавать другие значения Code.
Содержимое любых опций ND [IPv6-ND], которые не заданы для использования в IND Solicitation, должны игнорироваться с продолжением обычной обработки пакета. Кроме обязательных опций в сообщении может присутствовать лишь опция MTU.
Запрос IND Solicitation, прошедший проверку, называется действительным запросом (valid solicitation).
4.3.2. Проверка IND Advertisement
Узел должен отбрасывать без уведомления отправителя любые сообщения IND Advertisement, для которых не выполняются все приведённые ниже условия.
-
Поле IP Hop Limit имеет значение 255, т. е. пакет не передавался через маршрутизаторы.
-
При наличии заголовка IP AH аутентификация прошла успешно.
-
Значение ICMP Checksum действительно.
-
ICMP Code = 0.
-
Размер ICMP (выводится из размера IP) не менее 48 октетов.
-
Присутствует опция Source Link-Layer Address.
-
Присутствует опция Target Link-Layer Address.
-
Присутствует опция Target Address List.
-
Размер опции Target Address List не менее 3.
-
Все включённые опции имеют размер больше 0.
Содержимое поля Reserved и любые нераспознанные опции должны игнорироваться. Будущие изменения протокола, совместимые с прежними версиями, могут задавать содержимое поля Reserved и добавлять опции, несовместимые изменения могут задавать другие значения Code.
Содержимое любых опций ND [IPv6-ND], которые не заданы для использования в IND Solicitation, должны игнорироваться с продолжением обычной обработки пакета. Кроме обязательных опций в сообщении может присутствовать лишь опция MTU.
Анонс IND Advertisement, прошедший проверку, называется действительным анонсом (valid advertisement).
5. Вопросы безопасности
При использовании на виртуальных каналах «точка-точка», как в сетях Frame Relay, сообщения IND менее чувствительны к атакам с подменой со стороны узлов на канале, чем в случае широковещательных соединений.
Как и ND, протокол снижает раскрытие потоков для узлов вне канала в отсутствие аутентификации, игнорируя пакеты IND от размещённых вне канала отправителей. Поле Hop Limit во всех полученных пакетах имеет максимально допустимое значение 255. Поскольку маршрутизаторы декрементируют Hop Limit во всех пересылаемых пакетах, значение Hop Limit = 255 говорит о получении пакета от соседа.
Обмен пакетами протокола IND можно аутентифицировать с помощью IP AH [IPSEC-Auth]. Узлу следует включать заголовок AH при передаче пакетов IND, если имеется защищённая связь с адресатом для применения IP AH. Защищённую связь можно настроить вручную или с помощью того или иного протокола обмена ключами. Полученные в пакетах IND заголовки AH должны проверяться на корректность и при отказе пакеты должны отбрасываться.
При использовании с Frame Relay на приёмном узле после обработки IPSec должна выполняться специальная предварительная обработка Frame Relay для сообщений ND Solicitation с опцией Source Link-Layer Address, содержащей DLCI.
Администратору следует обеспечивать возможность настройки на узле игнорирования любых сообщений IND, подлинность которых не проверена с помощью AH или ESP. По умолчанию следует разрешать неаутентифицированные сообщения.
Вопросы конфиденциальности рассмотрены в документах IP Security Architecture и IP Encapsulating Security Payload [IPSEC], [IPSEC-ESP].
6. Взаимодействие с IANA
В IANA запрошено выделение двух новых типов ICMPv6, описанных в параграфах 2.1 и 2.2. Значения выбраны из числа информационных типов, как определено в параграфе 2.1 RFC 2463. Для этих типов не определены коды ICMPv6 (кроме 0), будущие назначения возможны по процедуре Standards Action, как указано в RFC 2434.
В IANA также запрошено выделение двух новых типов ICMPv6 Neighbor Discovery Option, как указано в параграфе 3.1. Внешнего обзора для них не потребовалось.
7. Благодарности
Спасибо Steve Deering, Thomas Narten, Erik Nordmark за обсуждение идеи IND, Thomas Narten, Erik Nordmark, а также Dan Harrington, Milan Merhar, Barbara Fox, Martin Mueller, Peter Tam за внимательное рецензирование.
Следует отметить, что часть текста спецификации заимствована из IPv6 Neighbor Discovery [IPv6-ND].
8. Литература
[IPv6] Deering, S. and R. Hinden, “Internet Protocol Version 6 Specification”, RFC 24601, December 1998.
[IPv6-ND] Narten, T., Nordmark, E. and W. Simpson “Neighbor Discovery for IP Version 6 (IPv6)”, RFC 24612, December 1998.
[ICMPv6] Conta, A., and S. Deering “Internet Control Message Protocol for the Internet Protocol Version 6”, RFC 24633, December 1998.
[IPv6-FR] Conta, A., Malis, A. and M. Mueller, “Transmission of IPv6 Packets over Frame Relay Networks”, RFC 2590, May 1999. December 1997.
[IPSEC] Atkinson, R. and S. Kent, “Security Architecture for the Internet Protocol”, RFC 24014, November 1998.
[IPSEC-Auth] Atkinson, R. and S. Kent, “IP Authentication Header”, RFC 24025, December 1998.
[IPSEC-ESP] Atkinson, R. and S. Kent, “IP Encapsulating Security Protocol (ESP)”, RFC 24066, November 1998.
[ASSIGN] Reynolds, J. and J. Postel, “Assigned Numbers”, STD 2, RFC 17007, March 1994.
[ENCAPS] Brown, C. and A. Malis, “Multiprotocol Interconnect over Frame Relay”, RFC 2427, November 1998.
[INV-ARP] Bradley, T., Brown, C. and A. Malis “Inverse Address Resolution Protocol”, RFC 2390, August 1998.
[KEYWORDS] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
9. Адрес автора
Alex Conta
Transwitch Corporation
3 Enterprise Drive
Shelton, CT 06484
Phone: +1-203-929-8810
EMail: aconta@txc.com
Перевод на русский язык
Николай Малых
Приложение A. IND в сетях Frame Relay
В этом приложении рассмотрены потребности применения IND в сетях Frame Relay, которые выходят за пределы базовых вопросов, рассмотренных в предыдущих параграфах.
A.1. Введение
Протокол IND применим к узлам Frame Relay. Постоянные (PVC) и коммутируемые (SVC) канала Frame Relay указываются идентификаторами DLCI (Data Link Connection Identifier). Каждый идентификатор DLCI определяет для узла Frame Relay одно виртуальное соединение через распределенную сеть (wide area network или WAN). Обычно DLCI имеют локальную значимость.
С помощью конкретных сигнальных сообщений сеть Frame Relay может анонсировать узлу новый виртуальный канал с соответствующим DLCI. Значение DLCI указывает узлу виртуальный канал и может служить эквивалентом адреса удалённого узла на канальном уровне, позволяя узлу идентифицировать канальный уровень на другой стороне виртуального канала. В примере на рисунке 1 узел A (локальный) указывает виртуальный канал к узлу B (удалённый) с помощью DLCI = 30. Однако сигнальное сообщение не содержит сведений о DLCI, используемом удаленным узлом для указания виртуального устройства локальному узлу, которое может служить эквивалентом адреса на канальном уровне. На рисунке 1 узел B (удалённый) может указать узлу A виртуальное устройство с помощью DLCI = 62.
~~~~~~~~~~~ Удаленный
{ } узел
+-----+ DLCI { } DLCI+-----+
| A |-30------{--+----+----+--}---------62-| B |
+-----+ { } +-----+
Локальный { } Облако сети
узел ~~~~~~~~~~~ Frame Relay
Рисунок 1.
Кроме того, передаваемое на канальном уровне сообщение не зависит от протокола IPv6 и не включает адресов IPv6. Протокол IND также позволяет узлу Frame Relay обнаруживать эквивалент локального адреса канального уровня, т. е. идентификатор, с помощью которого удалённый узел может указать его и, что более важно, определить адреса IPv6 на другой стороне виртуального канала, указанного удаленным адресом канального уровня.
Протокол IPv6 IND позволяет узлу Frame Relay динамически определять DLCI, по которому удалённый узел идентифицирует виртуальный канал, а также узнать адреса IPv6 узла на удалённой стороне виртуального канала.
A.2. Сообщения IND
A.2.1. IND Solicitation
Отправитель IND Solicitation не знает адрес IPv6 удалённого узла, но знает эквивалент его канального адреса. IND Solicitation передаются по групповому адресу IPv6 all-nodes [IPv6], [IPv6-FR], [ENCAPS], однако на канальном уровне сообщение передаётся целевому узлу напрямую по известному значению DLCI. Поля сообщения показаны ниже.
Source Link-Layer Address
Для передающего узла Frame Relay поле Source Link-Layer Address содержит эквивалент адреса канального уровня, по которому удалённый узел идентифицирует отправителя сообщения. Если отправителю известно это значение, его следует включить в поле, в противном случае поле следует оставить пустым. При наличии этой информации она может служить для отладки сети. Независимо от заполнения этого поля отправителем перед любой обработкой IND получатель сообщения заменяет это поле сведениями из заголовка Frame Relay (поле DLCI) в соответствии с форматом, заданным в [IPv6-FR].
Target Link-Layer Address
Передающий узел Frame Relay указывает в поле Target Link-Layer Address значение, эквивалентное адресу целевого узла на канальном уровне. Этим значением является DLCI виртуального канала VC к целевому узлу в формате, заданном [IPv6-FR].
Для иллюстрации создания сообщения IND Solicitation узлом Frame Relay рассмотрим узел A (рисунок 1), передающий IND Solicitation узлу B.
На узле A (отправитель IND Solicitation)
Source Link-Layer Address
DLCI=неизвестно (переписывается получателем).
Target Link-Layer Address
DLCI=30.
На узле B (получатель IND IND Solicitation)
Source Link-Layer Address
DLCI=62 (заполняется получателем).
Target Link-Layer Address
DLCI=30.
Примечание. Для Frame Relay приведённые выше адреса используют формат Q.922 (DLCI) с 10 (по умолчанию) или 23 значащими битами [IPv6-FR]. Размер опции (адрес канального уровня) указывается в 8-октетных блоках, поэтому DLCI извлекается из 8 байтов на основе поля EA (бит 0) второго, третьего и четвёртого октета (EA = 1). Поля C/R, FECN, BECN, DE в адресе Q.922 не имеют значения для IND и устанавливаются в 0 [IPv6-FR].
MTU
В опции MTU указывается значение MTU для виртуального канала, заданного известным DLCI [IPv6-FR].
A.2.2. IND Advertisement
Узел Frame Relay передаёт IND Advertisement в ответ на сообщение IND Solicitation. Поля сообщения указаны ниже.
Source Link-Layer Address
Для Frame Relay это поле копируется из поля Target Link-Layer Address в IND Solicitation в формате DLCI [IPv6-FR].
Target Link-Layer Address
Для Frame Relay это поле копируется из поля Source Link-Layer Address в IND Solicitation в формате DLCI [IPv6-FR].
Например, если узел B (рисунок 1) отвечает на IND Solicitation от узла A анонсом IND Advertisement, поля будут иметь вид, показанный ниже.
На узле B (отправитель анонса):
Source Link-Layer Address
DLCI=30 (Target в Solicitation).
Target Link-Layer Address
DLCI=62 (Source в Solicitation).
На узле A (получатель анонса от B).
Source Link-Layer Address
DLCI=30 (Target в Solicitation).
Target Link-Layer Address
DLCI=62 (Source в Solicitation).
Target Address List
Список адресов IPv6 на интерфейсе, указанном полем Target Link-Layer Address в IND Solicitation, вызвавшем анонс.
MTU
Значение MTU, заданное для канала (виртуального устройства) [IPv6-ND].
Примечание. В случае сетей Frame Relay сообщения IND передаются в виртуальный канал. При разрыве такого канала участники получают соответствующее сигнальное сообщения, которое распространяется на вышележащие уровни, включая IPv6.
A.3. Протокол IND
В этом параграфе описаны специфические для сетей Frame Relay аспекты IND.
A.3.1. Обработка на передающем узле
Запрашивающий узел Frame Relay форматирует сообщение IND Solicitation в соответствии с параграфом 2.1, инкапсулирует пакет для канального уровня Frame Relay [IPv6-FR] и передаёт его целевому узлу Frame Relay. Хотя IP-адресом получателя является групповой адрес IPv6 all-nodes, сообщение передаётся лишь целевому узлу Frame Relay, известному по виртуальному каналу.
A.3.2. Обработка на приёмном узле
A.3.2.1. Обработка сообщений IND Solicitation
Перед обработкой сообщения узел Frame Relay заменяет поле Source Link-Layer Address имеющимся значением DLCI из заголовка кадра Frame Relay с сообщением. Значение DLCI форматируется в соответствии с полем Source Link-Layer Address [IPv6-FR]. Это требуется для корректной интерпретации полей при последующей обработке сообщения IND Solicitation.
Для узла Frame Relay значение MTU из запроса можно использовать для установки в MTU у получателя более оптимального значения, если оно не задано при настройке конфигурации интерфейса.
A.3.2.2. Обработка сообщений IND Advertisement
Узел Frame Relay, получивший IND Advertisement, может поместить сопоставление адресов отправителя на канальном уровне и IPv6 из анонса IND Advertisement в свой кэш ND [IPv6-ND], как это делается для ND Advertisement.
Затем получатель IND Advertisement может сохранить Target Link-Layer Address из сообщения как значение DLCI удалённого узла на другой стороне VC. Это значение DLCI эквивалентно адресу канального уровня, по которому удалённый узел идентифицирует получателя.
Если получатель IND Advertisement имеет пул адресов IPv6 и реализация позволяет, он может «спарить» локальный адрес IPv6 с конкретным адресом IPv6 из полученного списка для последующих коммуникаций через VC. Более конкретно, спаривание следует выполнять для адресов IPv6 из одной подсети (общий префикс).
Полное заявление авторских прав
Copyright (C) The Internet Society (2001). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.
Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Подтверждение
Финансирование функций RFC Editor обеспечено Internet Society.