Internet Engineering Task Force (IETF) M. Boucadair Request for Comments: 7371 France Telecom Updates: 3306, 3956, 4291 S. Venaas Category: Standards Track Cisco ISSN: 2070-1721 September 2014
Updates to the IPv6 Multicast Addressing Architecture
Обновления архитектуры групповой адресации IPv6
Аннотация
Этот документ обновляет архитектуру групповой адресации IPv6 путём переопределения резервных битов как базовых флагов. В документе также даны некоторые разъяснения в части применения флагов.
Этот документ обновляет RFC3956, RFC3306, RFC4291.
Статус документа
Документ является проектом стандарт Internet (Internet Standards Track).
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Не все одобренные IESG документы претендуют на статус Internet Standard (см. раздел 2 в RFC 5741).
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc7371.
Авторские права
Авторские права (Copyright (c) 2014) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменён вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.
1. Введение
Этот документ обновляет архитектуру адресации IPv6 [RFC4291] путём переопределения резервных битов в качестве базовых флагов (раздел 2). В документе также даны некоторые разъяснения в части применения флагов (раздел 3).
Этот документ обновляет [RFC3956], [RFC3306], [RFC4291] в соответствии с новыми правилами обработки (раздел 3).
Текстовое представление адресов IPv6 следует рекомендациям [RFC5952].
1.1. Уровни требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [RFC2119].
2. Обновление архитектуры адресации
Биты 17-20 в групповом (multicast) адресе, где номер 1 имеет старший бит, определены в [RFC3956] и [RFC3306] как резервные. Этот документ определяет их в качестве базовых флагов, применимых ко всем групповым адресам. Эти биты обозначаются ff2 (flag field 2 — поле флагов 2), а биты flgs из [RFC4291] [RFC3956] обозначены как ff1 (flag field 1).
Задание битов 17-20 в качестве флагов для всех групповых адресов IPv6 позволяет более единообразно обрабатывать адреса и использовать в будущем эти биты для разных целей, независимо от конкретного типа multicast-адреса. Этот выбор исходно вызван документом [ADDR-FORMAT], где предложено связывать значение с одним из резервных битов. Кроме того, в [ADDR-FORMAT] рассматривается также использование последнего значимого бита в ff1, но от такого подхода отказались по причине отсутствия понимания в части других вариантов использования флага.
В разделе 4 приведены обновлённые спецификации архитектуры адресации. Назначение флагов может быть определено в будущих спецификациях.
3. Новые правила обработки флагов
В некоторых реализациях и спецификациях биты флагов рассматриваются не по отдельности, а как 4-битовое целое число. Такая практика препятствует присвоению значений оставшимся битам флагов. Ниже приведены примеры этого.
-
Из [RFC3306] можно сделать вывод, что ff3x::/32 является единственным разрешённым блоком префиксов IPv6 для заданной источником групповой адресации (Source-Specific Multicast или SSM).
-
В [RFC3956] указано, что для Embedded-RP3 применим лишь префикс ff70::/12. В частности, реализациям не следует рассматривать диапазон fff0::/12 как Embedded-RP.
Для предотвращения путаницы и однозначного назначения остальных флагов вносится приведённое ниже требование.
Реализация должна трактовать флаги как отдельные биты.
4. Обновления RFC
4.1. RFC 3306
4.1.1. Обновление 1
Этот документ меняет раздел 4 в [RFC3306], как показано ниже.
Прежнее
| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+--------+----------------+----------+
|11111111|flgs|scop|reserved| plen | network prefix | group ID |
+--------+----+----+--------+--------+----------------+----------+
Поле flgs представляется набором из 4 флагов
+-+-+-+-+ |0|0|P|T| +-+-+-+-+
P = 0 указывает групповой адрес, не назначенный на основе префикса сети. Это говорит о multicast-адресе, определённом в соответствии с [ADDRARCH].
P = 1 указывает групповой адрес, назначенный на основе префикса сети.
При P = 1 должно устанавливаться T = 1, в ином случае бит T определяется в соответствии с параграфом 2.7 в [ADDRARCH].
Резервное поле должно быть установлено в 0.
Примечание. Документ [ADDRARCH]4 был указан в [RFC3306], но сейчас заменён [RFC4291].
Новое
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+--------+----------------+----------+
|11111111|ff1 |scop|ff2 |rsvd| plen | network prefix | group ID |
+--------+----+----+----+----+--------+----------------+----------+
Поле флагов ff1 представляет собой набор из 4 битов
+-+-+-+-+ |X|Y|P|T| +-+-+-+-+
Биты X и Y могут иметь значение 0 или 1. Отметим, что X предназначен для выделения в будущем, а значение Y выделено в RFC 3956.
P = 0 указывает групповой адрес, не назначенный на основе префикса сети. Это говорит о multicast-адресе, определённом в соответствии с [RFC4291].
P = 1 указывает групповой адрес, назначенный на основе префикса сети.
При P = 1 должно устанавливаться T = 1, в ином случае бит T определяется в соответствии с параграфом [RFC4291].
Поле флагов ff2 представляет собой набор из 4 битов
+-+-+-+-+ |r|r|r|r| +-+-+-+-+
где rrrr – биты для выделения в будущем в качестве флагов. Каждый из битов r должен сбрасываться (0) при передаче, а получатель должен игнорировать эти биты.
Битами флагов считаются ff1 и ff2.
4.1.2. Обновление 2
Этот документ меняет раздел 6 в [RFC3306], как показано ниже.
Прежнее
Эти установки создают диапазон SSM5 FF3x::/32 (x – любая область действия). Поле адреса отправителя в заголовке IPv6 указывает владельца multicast-адреса.
Новое
Если биты поля ff1 установлены в 0011, это создаёт диапазон SSM ff3x::/32 (x – любая область действия). Поле адреса отправителя в заголовке IPv6 указывает владельца multicast-адреса. Префикс ff3x::/32 не является единственным разрешённым префиксом SSM. Например, при установке старшего бита в поле ff1 будет получен диапазон SSM ffbx::/32.
4.2. RFC 3956
4.2.1. Обновление 1
Этот документ меняет раздел 2 в [RFC3956], как показано ниже.
Прежнее
Как описано в [RFC3306], групповой адрес имеет формат, показанный на рисунке.
| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+----+----------------+----------+
|11111111|flgs|scop|reserved|plen| network prefix | group ID |
+--------+----+----+--------+----+----------------+----------+
Где поле flgs имеет значение 0011 (первые два бита ещё не определены, устанавливаются в 0 при передаче и игнорируются при получении).
Новое
Групповой адрес имеет формат, показанный на рисунке ниже.
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+----+----------------+----------+
|11111111|ff1 |scop|ff2 |rsvd|plen| network prefix | group ID |
+--------+----+----+----+----+----+----------------+----------+
Поле флагов ff1 состоит из 4 битов
+-+-+-+-+ |X|R|P|T| +-+-+-+-+
где бит X оставлен для будущего использования в качестве дополнительного флага и может иметь значение 0 или 1.
Поле флагов ff2 состоит из 4 битов
+-+-+-+-+ |r|r|r|r| +-+-+-+-+
где биты rrrr оставлены для будущего использования в качестве дополнительных флагов. Биты r должны сбрасываться (0) при передаче, а получатель должен игнорировать их.
Битами флагов считаются ff1 и ff2.
4.2.2. Обновление 2
Этот документ меняет раздел 3 в [RFC3956], как показано ниже.
Прежнее
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+----+----------------+----------+
|11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID |
+--------+----+----+----+----+----+----------------+----------+
Поле flgs является набором из 4 флагов
+-+-+-+-+ |0|R|P|T| +-+-+-+-+
Когда старший бит имеет значение 0, установка R = 1 указывает групповой адрес со встроенным адресом RP6. Тогда должно устанавливаться P = 1 и, следовательно, в соответствии с [RFC3306] должно устанавливаться T = 1. Фактически это подразумевает префикс FF70::/12. В этом случае последние 4 бита ранее зарезервированного поля интерпретируются как идентификатор встроенного интерфейса, как задаёт этот документ.
Поведение не задаётся для случаев, когда P или T не имеет значения 1, поскольку префикс в этом случае отличается от FF70::/12. Аналогичным образом кодирование и режим протокола, используемые при установке для двух старших битов поля flgs значения 11 (FFF0::/12), намеренно не заданы, пока не определён старший бит. Без дополнительной спецификации IETF реализациям не следует считать диапазон FFF0::/12 встроенным RP (Embedded-RP).
Новое
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+----+----------------+----------+
|11111111|ff1 |scop|ff2 |RIID|plen| network prefix | group ID |
+--------+----+----+----+----+----+----------------+----------+
Поле ff1 является набором из 4 флагов
+-+-+-+-+ |X|R|P|T| +-+-+-+-+
где бит X оставлен для будущего использования в качестве дополнительного флага и может иметь значение 0 или 1.
R = 1 указывает групповой адрес со встроенным RP. Тогда для P должно устанавливаться значение 1 и, следовательно, в соответствии с [RFC3306] должно устанавливаться T = 1, поскольку это является особым случаем адреса на основе unicast-префикса. Это означает, например, что префиксы ff70::/12 и fff0::/12 являются префиксами со встроенным RP. При установленном бите R последние 4 бита поля, которые были резервными в [RFC3306], интерпретируются как встраивание идентификатора интерфейса RP, заданное этим документом.
4.2.3. Обновление 3
Этот документ меняет раздел 4 в [RFC3956], как показано ниже.
Прежнее
-
Это должен быть групповой адрес с flgs = 0111, т. е. префикс FF70::/12.
Новое
-
Это должен быть групповой адрес с R = 1.
-
Биты P и T должны быть установлены (1) при использовании встраивания в этом документе, поскольку это основанный на префиксе адрес.
4.2.4. Обновление 4
Этот документ меняет параграф 7.1 в [RFC3956], как показано ниже.
Прежнее
Для предотвращения петель и несогласованности с адресами из диапазона FF70::/12 отображение Embedded-RP должно считаться самым длинным совпадением и более высоким приоритетом, чем у любого другого механизма.
Новое
Для предотвращения петель и несогласованности с адресами, где установлено R = 1, отображение Embedded-RP должно считаться самым длинным совпадением и более высоким приоритетом, чем у любого другого механизма.
5. Вопросы безопасности
Следует принимать во внимание вопросы безопасности, рассмотренные в [RFC3956], [RFC3306] и [RFC4291].
6. Благодарности
Большое спасибо Brian Haberman за обсуждение документа перед публикацией.
Большое спасибо Jouni Korhonen, Tatuya Jinmei, Charlie Kaufman, Ben Campbell за рецензии.
7. Литература
7.1. Нормативные документы
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC3306] Haberman, B. and D. Thaler, “Unicast-Prefix-based IPv6 Multicast Addresses”, RFC 3306, August 2002.
[RFC3956] Savola, P. and B. Haberman, “Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address”, RFC 3956, November 2004.
[RFC4291] Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture”, RFC 4291, February 2006.
[RFC5952] Kawamura, S. and M. Kawashima, “A Recommendation for IPv6 Address Text Representation”, RFC 5952, August 2010.
7.2. Дополнительная литература
[ADDR-FORMAT] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, “IPv6 Multicast Address With Embedded IPv4 Multicast Address”, Work in Progress, April 2013.
Адреса авторов
Mohamed Boucadair
France Telecom
Rennes 35000
France
EMail: mohamed.boucadair@orange.com
Stig Venaas
Cisco
USA
EMail: stig@cisco.com
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force.
2Internet Engineering Steering Group.
3Embedded Rendezvous Point – встроенная точка встречи.
5Source-specific multicast – заданная отправителем групповая адресация.
6Rendezvous Point – точка встречи.