RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification

image_print
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 для реверсного обнаружения

PDF

Статус документа

В этом документе приведена спецификация проекта стандартного протокола 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


Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Приложение 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). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Документ заменён RFC 8200. Прим. перев.

2Документ заменён RFC 4861. Прим. перев.

3Документ заменён RFC 4443. Прим. перев.

4Документ заменён RFC 4301. Прим. перев.

5Документ заменён RFC 4302 и RFC 4305. Прим. перев.

6Документ заменён RFC 4303 и RFC 4305. Прим. перев.

7В соответствии с RFC 3232 документ заменён базой данных, доступной по ссылке.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

Добавить комментарий