Administratively Scoped IP Multicast
RFC 2365 определяет административно ограниченное пространство IPv4 multicast: 239.0.0.0–239.255.255.255. Документ задаёт семантику граничных маршрутизаторов, локальное назначение адресов и правила топологии областей, включая IPv4 Local Scope 239.255.0.0/16 и IPv4 Organization Local Scope 239.192.0.0/14. Он также устанавливает сопоставление префиксов IPv4 multicast со значениями IPv6 SCOP. Документ предупреждает, что на административные границы не следует полагаться для предотвращения выхода чувствительных данных; организациям, передающим такие данные, следует использовать отдельный механизм конфиденциальности, например шифрование.
Network Working Group D. Meyer
Request for Comments: 2365 University of Oregon
BCP: 23 July 1998
Category: Best Current Practice
IP-многоадресная рассылка с административной областью действия
Статус этого меморандума
Этот документ определяет Лучшую современную практику Интернета для интернет-сообщества и запрашивает обсуждение и предложения по улучшениям. Распространение этого меморандума не ограничено.
Уведомление об авторском праве
Copyright (C) The Internet Society (1998). Все права защищены.
1. Аннотация
Этот документ определяет «пространство IPv4-адресов многоадресной рассылки с административной областью действия» как диапазон от 239.0.0.0 до 239.255.255.255. Кроме того, он описывает простой набор семантических правил для реализации IP-многоадресной рассылки с административной областью действия. Наконец, он задаёт соответствие между классами IPv6-адресов многоадресной рассылки [RFC1884] и классами IPv4-адресов многоадресной рассылки.
Этот меморандум является результатом работы MBONE Deployment Working Group (MBONED) в области эксплуатации и управления Internet Engineering Task Force. Направляйте комментарии по адресу <mboned@ns.uoregon.edu> или автору.
2. Благодарности
Значительная часть этого меморандума взята из «Administratively Scoped IP Multicast», Van Jacobson и Steve Deering, представленного на 30-й встрече IETF в Торонто, Канада, 25 июля 1994 года. Steve Casner, Mark Handley и Dave Thaler также предоставили проницательные комментарии к более ранним версиям этого документа.
3. Введение
Большинство современных реализаций IP-многоадресной рассылки достигают некоторого уровня ограничения области действия, используя поле TTL в IP-заголовке. Типичная практика MBONE (Multicast Backbone) состояла в проектировании порогов TTL, ограничивающих трафик некоторой административно определённой топологической областью. Базовое правило пересылки для интерфейсов с настроенными порогами TTL состоит в том, что пакет не пересылается через интерфейс, если его оставшийся TTL не превышает порог.
Meyer Best Current Practice [Page 1]
RFC 2365 Administratively Scoped IP Multicast July 1998
Ограничение области действия по TTL применялось для управления распространением трафика многоадресной рассылки с целью уменьшить нагрузку на дефицитные ресурсы (например, пропускную способность) либо добиться некоторого улучшения свойств приватности или масштабируемости. Кроме того, TTL также используется в своей традиционной роли для ограничения времени жизни дейтаграммы. С учётом этих часто конфликтующих ролей ограничение области действия по TTL оказалось трудно надёжно реализовать, а получающиеся схемы часто были сложными и трудными для понимания.
Более серьёзная архитектурная проблема касается взаимодействия ограничения области действия по TTL с протоколами широковещательной рассылки и отсечения (например, DVMRP [DVMRP]). Конкретная проблема состоит в том, что во многих распространённых случаях ограничение области действия по TTL может препятствовать эффективности отсечения. Рассмотрим случай, в котором TTL пакета либо истёк, либо не прошёл порог TTL. Маршрутизатор, отбрасывающий пакет, не сможет выполнить отсечение каких-либо источников выше по потоку и, следовательно, будет принимать весь трафик многоадресной рассылки (независимо от того, имеются ли получатели ниже по потоку). Заметим, что, хотя может показаться возможным посылать сообщения отсечения выше по потоку от точки, в которой пакет отбрасывается, эта стратегия может привести к отбрасыванию законного трафика, поскольку последующие пакеты могут пойти другим путём и прийти в ту же точку с большим TTL.
С другой стороны, IP-многоадресная рассылка с административной областью действия может предоставить ясную и простую семантику для IP-многоадресной рассылки с ограниченной областью действия. Ключевые свойства IP-многоадресной рассылки с административной областью действия состоят в том, что (i). пакеты, адресованные адресам многоадресной рассылки с административной областью действия, не пересекают настроенные административные границы, и (ii). адреса многоадресной рассылки с административной областью действия назначаются локально и поэтому не обязаны быть уникальными между административными границами.
4. Определение пространства IPv4-адресов многоадресной рассылки с административной областью действия
Пространство IPv4-адресов многоадресной рассылки с административной областью действия определяется как диапазон от 239.0.0.0 до 239.255.255.255.
5. Обсуждение
Для поддержки IP-многоадресной рассылки с административной областью действия маршрутизатору следует поддерживать настройку границ IP-многоадресной рассылки с ограниченной областью действия для каждого интерфейса. Такой маршрутизатор, называемый граничным маршрутизатором, не пересылает в обоих направлениях пакеты, соответствующие определению границы интерфейса (двунаправленная проверка предотвращает проблемы с сетями множественного доступа). Кроме того, граничный маршрутизатор всегда выполняет отсечение границы для групп плотного режима [PIMDM] и не принимает присоединения для групп разреженного режима [PIMSM] в диапазоне с административной областью действия.
Meyer Best Current Practice [Page 2]
RFC 2365 Administratively Scoped IP Multicast July 1998
6. Структура пространства многоадресной рассылки с административной областью действия
Структура пространства IP version 4 для многоадресной рассылки с административной областью действия в общих чертах основана на архитектуре адресации IP Version 6, описанной в RFC 1884 [RFC1884]. Этот документ определяет две важные области действия: IPv4 Local Scope и IPv4 Organization Local Scope. Эти области действия описаны ниже.
6.1. IPv4 Local Scope -- 239.255.0.0/16
239.255.0.0/16 определяется как IPv4 Local Scope. Local Scope является минимальной охватывающей областью действия и поэтому далее не делится. Хотя точный охват Local Scope зависит от площадки, локально ограниченные области должны соблюдать определённые топологические ограничения. В частности, Local Scope не должна пересекать какую-либо другую границу области действия. Кроме того, Local Scope должна полностью содержаться в любой большей области действия либо быть равной ей. Если области действия перекрываются по территории, область перекрытия должна находиться в собственной локальной области действия. Отсюда следует, что любая граница области действия также является границей для Local Scope. Более общие топологические требования к областям с административной областью действия обсуждаются ниже.
6.1.1. Расширение IPv4 Local Scope
Пространство IPv4 Local Scope растёт «вниз». Поэтому IPv4 Local Scope может расти вниз от 239.255.0.0/16 в зарезервированные диапазоны 239.254.0.0/16 и 239.253.0.0/16. Однако эти диапазоны не следует использовать, пока пространства 239.255.0.0/16 больше не достаточно.
6.2. IPv4 Organization Local Scope -- 239.192.0.0/14
239.192.0.0/14 определяется как IPv4 Organization Local Scope и является пространством, из которого организациям следует выделять поддиапазоны при определении областей действия для частного использования.
6.2.1. Расширение IPv4 Organization Local Scope
Диапазоны 239.0.0.0/10, 239.64.0.0/10 и 239.128.0.0/10 не назначены и доступны для расширения этого пространства. Эти диапазоны следует оставлять неназначенными, пока пространства 239.192.0.0/14 больше не достаточно. Это позволяет учесть возможность того, что будущие редакции этого документа могут определить дополнительные области действия большего, чем организации, масштаба.
6.3. Другие представляющие интерес области IPv4
Два других представляющих интерес класса областей действия — статически назначенная область действия, локальная для канала, и глобальная область действия — уже существуют в пространстве IPv4-многоадресной рассылки.
Meyer Best Current Practice [Page 3]
RFC 2365 Administratively Scoped IP Multicast July 1998
Статически назначенная область действия, локальная для канала, — 224.0.0.0/24. Существующие статические выделения глобальной области действия несколько более детализированы и включают
224.1.0.0-224.1.255.255 Группы многоадресной рассылки ST
224.2.0.0-224.2.127.253 Вызовы мультимедийных конференций
224.2.127.254 Объявления SAPv1
224.2.127.255 Объявления SAPv0 (устарело)
224.2.128.0-224.2.255.255 Динамические назначения SAP
224.252.0.0-224.255.255.255 Временные группы DIS
232.0.0.0-232.255.255.255 Временные группы VMTP
См. [RFC1700] для текущих назначений адресов многоадресной рассылки (этот список также можно найти, возможно в более актуальной форме, по адресу ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses).
7. Топологические требования к административным границам
Область IP-многоадресной рассылки с административной областью действия определяется как топологическая область, в которой имеется один или несколько граничных маршрутизаторов с общими определениями границы. О таком маршрутизаторе говорят, что он является границей для адресов с ограниченной областью действия в диапазоне, определённом его конфигурацией.
Администраторы сети могут настраивать область действия, когда требуется ограниченная область IP-многоадресной рассылки. Кроме того, администратор может при необходимости настраивать перекрывающиеся области действия (сети могут находиться в нескольких областях действия), с единственными ограничениями: область действия должна быть связной (между любыми двумя узлами в области действия должен существовать путь, не выходящий за её пределы) и выпуклой (то есть никакой путь между любыми двумя точками области не может пересекать границу области). Однако важно отметить, что, если области с административной областью действия топологически пересекаются, внешняя область действия должна состоять из её адресного пространства за вычетом адресных пространств всех пересекающихся областей действия. Это требование предотвращает проблему, которая возникла бы, когда путь между двумя точками в выпуклой области пересекает границу пересекающейся области. По этой причине рекомендуется, чтобы административные области действия, которые топологически пересекаются, не пересекались по диапазону адресов.
Наконец, отметим, что любая граница области действия является границей для Local Scope. Отсюда следует, что пакеты, отправленные группам, охватываемым 239.255.0.0/16, не должны пересылаться через какой-либо канал, для которого определена граница с ограниченной областью действия.
Meyer Best Current Practice [Page 4]
RFC 2365 Administratively Scoped IP Multicast July 1998
8. Разбиение пространства многоадресной рассылки с административной областью действия
Следующая таблица показывает разбиение пространства IPv4-многоадресной рассылки и задаёт соответствие между IPv4-префиксами многоадресной рассылки и значениями IPv6 SCOP:
IPv6 SCOP Описание RFC 1884 IPv4-префикс
===============================================================
0 зарезервировано
1 область действия, локальная для узла
2 область действия, локальная для канала 224.0.0.0/24
3 (не назначено) 239.255.0.0/16
4 (не назначено)
5 область действия, локальная для площадки
6 (не назначено)
7 (не назначено)
8 область действия, локальная для организации 239.192.0.0/14
A (не назначено)
B (не назначено)
C (не назначено)
D (не назначено)
E глобальная область действия 224.0.1.0-238.255.255.255
F зарезервировано
(не назначено) 239.0.0.0/10
(не назначено) 239.64.0.0/10
(не назначено) 239.128.0.0/10
9. Структура и использование области с ограниченной областью действия
Старший /24 в каждой области с ограниченной областью действия зарезервирован для относительных назначений. Относительное назначение представляет собой целочисленное смещение от наибольшего адреса в области действия и представляет 32-битный адрес (для IPv4). Например, в определённой выше Local Scope 239.255.255.0/24 зарезервирован для относительных выделений. Фактическое относительное назначение «0» (то есть 239.255.255.255 в Local Scope) в настоящее время существует для SAP [SAP]. Следующее относительное назначение, «1», соответствует адресу 239.255.255.254 в Local Scope. Остальная часть области с ограниченной областью действия ниже зарезервированного /24 доступна для динамического назначения (предположительно протоколом выделения адресов).
Важно отметить, что для практического использования областей действия, кроме Local Scope, потребуется разработать протокол обнаружения областей действия [MZAP]. Кроме того, поскольку любое использование любой области с административной областью действия, включая Local Scope, требует динамически назначаемой адресации, для того чтобы административное ограничение области действия стало в целом полезным, потребуется разработать Address Allocation Protocol (AAP).
Meyer Best Current Practice [Page 5]
RFC 2365 Administratively Scoped IP Multicast July 1998
9.1. Руководство по относительным назначениям
Запросы на относительные назначения следует направлять в IANA. При выполнении относительных назначений адресов IANA будет консультироваться с экспертом области. Эксперт области будет назначен соответствующим Area Director.
В общем случае относительные адреса будут использоваться только для начальной загрузки перехода к динамическим назначениям адресов изнутри области действия. Поэтому относительные назначения следует выполнять только для тех служб, которые не могут использовать протокол динамического назначения адресов для обнаружения адреса, используемого этой службой в желаемой области действия, например для самой службы динамического назначения адресов.
10. Соображения безопасности
Организациям, использующим IP-адреса многоадресной рассылки с административной областью действия, рекомендуется не полагаться на них для предотвращения передачи конфиденциальных данных за пределы организации. Если маршрутизатор многоадресной рассылки на административной границе будет неправильно настроен, будет содержать ошибку в коде административного ограничения области действия либо иметь иные проблемы, из-за которых этот маршрутизатор будет пересылать пакет IP-многоадресной рассылки с административной областью действия за пределы надлежащей области действия, данные организации покинут назначенную для их передачи область. Организациям, использующим IP-многоадресную передачу с административной областью действия для передачи конфиденциальных данных, следует использовать какой-либо механизм обеспечения конфиденциальности (например, шифрование) для защиты этих данных. В случае многих существующих приложений для видеоконференций (например, vat) шифрование доступно как функция приложения и его лишь необходимо включить (а также надлежащим образом безопасно распространить криптографические ключи). Для многих других приложений использование IP Encapsulating Security Payload (ESP) [RFC-1825, RFC-1827] может обеспечивать конфиденциальность на IP-уровне посредством шифрования.
В контексте группы IP-многоадресной передачи с административной областью действия использование ручного распределения ключей вполне может быть осуществимым. Хотя динамическое управление ключами для IP Security на момент написания этой заметки является областью исследований, ожидается, что в будущем IETF расширит протокол управления ключами ISAKMP для поддержки масштабируемого распределения ключей многоадресной передачи.
Важно отметить, что описываемый в этой заметке «пограничный маршрутизатор» не обязательно предоставляет какие-либо возможности межсетевого экрана.
Meyer Best Current Practice [Page 6]
RFC 2365 Administratively Scoped IP Multicast July 1998
11. Ссылки
[ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP
Multicast", представлено на 30-м IETF, Toronto, Canada, 25
July 1994.
[DVMRP] Pusateri, T., "Distance Vector Multicast Routing Protocol",
Work in Progress.
[MZAP] Handley, M., "Multicast-Scope Zone Announcement Protocol
(MZAP)", Work in Progress.
[PIMDM] Deering, S, et. al., "Protocol Independent Multicast
Version 2, Dense Mode Specification", Work in Progress.
[PIMSM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
Wei, "Protocol Independent Multicast Sparse Mode (PIM-SM):
Protocol Specification", RFC 2362, June 1998.
[RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[RFC1884] Hinden. R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC1884, December 1995.
[SAP] Handley, M., "SAP: Session Announcement Protocol", Work in
Progress.
12. Адрес автора
David Meyer
Cisco Systems
San Jose, CA
EMail: dmm@cisco.com
Meyer Best Current Practice [Page 7]
RFC 2365 Administratively Scoped IP Multicast July 1998
13. Полное заявление об авторском праве
Copyright (C) The Internet Society (1998). All Rights Reserved.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, содержащие комментарии к нему, иным образом разъясняющие его или содействующие его реализации, могут подготавливаться, копироваться, публиковаться и распространяться, полностью или частично, без каких-либо ограничений при условии, что приведённое выше уведомление об авторском праве и этот абзац включены во все такие копии и производные работы. Однако сам этот документ не может быть каким-либо образом изменён, например путём удаления уведомления об авторском праве или ссылок на The Internet Society либо другие интернет-организации, за исключением случаев, когда это необходимо для разработки стандартов Интернета, в котором случае должны соблюдаться процедуры в отношении авторских прав, определённые процессом разработки стандартов Интернета, или когда это требуется для его перевода на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут отозваны The Internet Society либо её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях «КАК ЕСТЬ», И THE INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Meyer Best Current Practice [Page 8]
Network Working Group D. Meyer
Request for Comments: 2365 University of Oregon
BCP: 23 July 1998
Category: Best Current Practice
Administratively Scoped IP Multicast
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
1. Abstract
This document defines the "administratively scoped IPv4 multicast
space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it
describes a simple set of semantics for the implementation of
Administratively Scoped IP Multicast. Finally, it provides a mapping
between the IPv6 multicast address classes [RFC1884] and IPv4
multicast address classes.
This memo is a product of the MBONE Deployment Working Group (MBONED)
in the Operations and Management Area of the Internet Engineering
Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author.
2. Acknowledgments
Much of this memo is taken from "Administratively Scoped IP
Multicast", Van Jacobson and Steve Deering, presented at the 30th
IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and
Dave Thaler have also provided insightful comments on earlier
versions of this document.
3. Introduction
Most current IP multicast implementations achieve some level of
scoping by using the TTL field in the IP header. Typical MBONE
(Multicast Backbone) usage has been to engineer TTL thresholds that
confine traffic to some administratively defined topological region.
The basic forwarding rule for interfaces with configured TTL
thresholds is that a packet is not forwarded across the interface
unless its remaining TTL is greater than the threshold.
Meyer Best Current Practice [Page 1]
RFC 2365 Administratively Scoped IP Multicast July 1998
TTL scoping has been used to control the distribution of multicast
traffic with the objective of easing stress on scarce resources
(e.g., bandwidth), or to achieve some kind of improved privacy or
scaling properties. In addition, the TTL is also used in its
traditional role to limit datagram lifetime. Given these often
conflicting roles, TTL scoping has proven difficult to implement
reliably, and the resulting schemes have often been complex and
difficult to understand.
A more serious architectural problem concerns the interaction of TTL
scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]). The
particular problem is that in many common cases, TTL scoping can
prevent pruning from being effective. Consider the case in which a
packet has either had its TTL expire or failed a TTL threshold. The
router which discards the packet will not be capable of pruning any
upstream sources, and thus will sink all multicast traffic (whether
or not there are downstream receivers). Note that while it might seem
possible to send prunes upstream from the point at which a packet is
discarded, this strategy can result in legitimate traffic being
discarded, since subsequent packets could take a different path and
arrive at the same point with a larger TTL.
On the other hand, administratively scoped IP multicast can provide
clear and simple semantics for scoped IP multicast. The key
properties of administratively scoped IP multicast are that (i).
packets addressed to administratively scoped multicast addresses do
not cross configured administrative boundaries, and (ii).
administratively scoped multicast addresses are locally assigned, and
hence are not required to be unique across administrative boundaries.
4. Definition of the Administratively Scoped IPv4 Multicast Space
The administratively scoped IPv4 multicast address space is defined
to be the range 239.0.0.0 to 239.255.255.255.
5. Discussion
In order to support administratively scoped IP multicast, a router
should support the configuration of per-interface scoped IP multicast
boundaries. Such a router, called a boundary router, does not forward
packets matching an interface's boundary definition in either
direction (the bi-directional check prevents problems with multi-
access networks). In addition, a boundary router always prunes the
boundary for dense-mode groups [PIMDM], and doesn't accept joins for
sparse-mode groups [PIMSM] in the administratively scoped range.
Meyer Best Current Practice [Page 2]
RFC 2365 Administratively Scoped IP Multicast July 1998
6. The Structure of the Administratively Scoped Multicast Space
The structure of the IP version 4 administratively scoped multicast
space is loosely based on the IP Version 6 Addressing Architecture
described in RFC 1884 [RFC1884]. This document defines two important
scopes: the IPv4 Local Scope and IPv4 Organization Local Scope. These
scopes are described below.
6.1. The IPv4 Local Scope -- 239.255.0.0/16
239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local
Scope is the minimal enclosing scope, and hence is not further
divisible. Although the exact extent of a Local Scope is site
dependent, locally scoped regions must obey certain topological
constraints. In particular, a Local Scope must not span any other
scope boundary. Further, a Local Scope must be completely contained
within or equal to any larger scope. In the event that scope regions
overlap in area, the area of overlap must be in its own local scope.
This implies that any scope boundary is also a boundary for the Local
Scope. The more general topological requirements for administratively
scoped regions are discussed below.
6.1.1. Expansion of the IPv4 Local Scope
The IPv4 Local Scope space grows "downward". As such, the IPv4 Local
Scope may grow downward from 239.255.0.0/16 into the reserved ranges
239.254.0.0/16 and 239.253.0.0/16. However, these ranges should not
be utilized until the 239.255.0.0/16 space is no longer sufficient.
6.2. The IPv4 Organization Local Scope -- 239.192.0.0/14
239.192.0.0/14 is defined to be the IPv4 Organization Local Scope,
and is the space from which an organization should allocate sub-
ranges when defining scopes for private use.
6.2.1. Expansion of the IPv4 Organization Local Scope
The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are
unassigned and available for expansion of this space. These ranges
should be left unassigned until the 239.192.0.0/14 space is no longer
sufficient. This is to allow for the possibility that future
revisions of this document may define additional scopes on a scale
larger than organizations.
6.3. Other IPv4 Scopes of Interest
The other two scope classes of interest, statically assigned link-
local scope and global scope already exist in IPv4 multicast space.
Meyer Best Current Practice [Page 3]
RFC 2365 Administratively Scoped IP Multicast July 1998
The statically assigned link-local scope is 224.0.0.0/24. The
existing static global scope allocations are somewhat more granular,
and include
224.1.0.0-224.1.255.255 ST Multicast Groups
224.2.0.0-224.2.127.253 Multimedia Conference Calls
224.2.127.254 SAPv1 Announcements
224.2.127.255 SAPv0 Announcements (deprecated)
224.2.128.0-224.2.255.255 SAP Dynamic Assignments
224.252.0.0-224.255.255.255 DIS transient groups
232.0.0.0-232.255.255.255 VMTP transient groups
See [RFC1700] for current multicast address assignments (this list
can also be found, possibly in a more current form, on
ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses).
7. Topological Requirements for Administrative Boundaries
An administratively scoped IP multicast region is defined to be a
topological region in which there are one or more boundary routers
with common boundary definitions. Such a router is said to be a
boundary for scoped addresses in the range defined in its
configuration.
Network administrators may configure a scope region whenever
constrained multicast scope is required. In addition, an
administrator may configure overlapping scope regions (networks can
be in multiple scope regions) where convenient, with the only
limitations being that a scope region must be connected (there must
be a path between any two nodes within a scope region that doesn't
leave that region), and convex (i.e., no path between any two points
in the region can cross a region boundary). However, it is important
to note that if administratively scoped areas intersect
topologically, then the outer scope must consist of its address space
minus the address spaces of any intersecting scopes. This requirement
prevents the problem that would arise when a path between two points
in a convex region crosses the boundary of an intersecting region.
For this reason, it is recommended that administrative scopes that
intersect topologically should not intersect in address range.
Finally, note that any scope boundary is a boundary for the Local
Scope. This implies that packets sent to groups covered by
239.255.0.0/16 must not be forwarded across any link for which a
scoped boundary is defined.
Meyer Best Current Practice [Page 4]
RFC 2365 Administratively Scoped IP Multicast July 1998
8. Partitioning of the Administratively Scoped Multicast Space
The following table outlines the partitioning of the IPv4 multicast
space, and gives the mapping from IPv4 multicast prefixes to IPv6
SCOP values:
IPv6 SCOP RFC 1884 Description IPv4 Prefix
===============================================================
0 reserved
1 node-local scope
2 link-local scope 224.0.0.0/24
3 (unassigned) 239.255.0.0/16
4 (unassigned)
5 site-local scope
6 (unassigned)
7 (unassigned)
8 organization-local scope 239.192.0.0/14
A (unassigned)
B (unassigned)
C (unassigned)
D (unassigned)
E global scope 224.0.1.0-238.255.255.255
F reserved
(unassigned) 239.0.0.0/10
(unassigned) 239.64.0.0/10
(unassigned) 239.128.0.0/10
9. Structure and Use of a Scoped Region
The high order /24 in every scoped region is reserved for relative
assignments. A relative assignment is an integer offset from highest
address in the scope and represents a 32-bit address (for IPv4). For
example, in the Local Scope defined above, 239.255.255.0/24 is
reserved for relative allocations. The de-facto relative assignment
"0", (i.e., 239.255.255.255 in the Local Scope) currently exists for
SAP [SAP]. The next relative assignment, "1", corresponds to the
address 239.255.255.254 in the Local Scope. The rest of a scoped
region below the reserved /24 is available for dynamic assignment
(presumably by an address allocation protocol).
In is important to note that a scope discovery protocol [MZAP] will
have to be developed to make practical use of scopes other than the
Local Scope. In addition, since any use of any administratively
scoped region, including the Local Scope, requires dynamically
assigned addressing, an Address Allocation Protocol (AAP) will need
to be developed to make administrative scoping generally useful.
Meyer Best Current Practice [Page 5]
RFC 2365 Administratively Scoped IP Multicast July 1998
9.1. Relative Assignment Guidelines
Requests for relative assignments should be directed to the IANA. The
IANA will be advised by an area expert when making relative address
assignments. The area expert will be appointed by the relevant Area
Director.
In general, relative addresses will be used only for bootstrapping to
dynamic address assignments from within the scope. As such, relative
assignments should only be made to those services that cannot use a
dynamic address assignment protocol to find the address used by that
service within the desired scope, such as a dynamic address
assignment service itself.
10. Security Considerations
It is recommended that organizations using the administratively
scoped IP Multicast addresses not rely on them to prevent sensitive
data from being transmitted outside the organization. Should a
multicast router on an administrative boundary be mis-configured,
have a bug in the administrative scoping code, or have other problems
that would cause that router to forward an administratively scoped IP
multicast packet outside of the proper scope, the organizations data
would leave its intended transmission region.
Organizations using administratively scoped IP Multicasting to
transmit sensitive data should use some confidentiality mechanism
(e.g. encryption) to protect that data. In the case of many existing
video-conferencing applications (e.g. vat), encryption is available
as an application feature and merely needs to be enabled (and
appropriate cryptographic keys securely distributed). For many other
applications, the use of the IP Encapsulating Security Payload (ESP)
[RFC-1825, RFC-1827] can provide IP-layer confidentiality though
encryption.
Within the context of an administratively scoped IP multicast group,
the use of manual key distribution might well be feasible. While
dynamic key management for IP Security is a research area at the time
this note is written, it is expected that the IETF will be extending
the ISAKMP key management protocol to support scalable multicast key
distribution in the future.
It is important to note that the "boundary router" described in this
note is not necessarily providing any kind of firewall capability.
Meyer Best Current Practice [Page 6]
RFC 2365 Administratively Scoped IP Multicast July 1998
11. References
[ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP
Multicast", presented at the 30th IETF, Toronto, Canada, 25
July 1994.
[DVMRP] Pusateri, T., "Distance Vector Multicast Routing Protocol",
Work in Progress.
[MZAP] Handley, M., "Multicast-Scope Zone Announcement Protocol
(MZAP)", Work in Progress.
[PIMDM] Deering, S, et. al., "Protocol Independent Multicast
Version 2, Dense Mode Specification", Work in Progress.
[PIMSM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
Wei, "Protocol Independent Multicast Sparse Mode (PIM-SM):
Protocol Specification", RFC 2362, June 1998.
[RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[RFC1884] Hinden. R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC1884, December 1995.
[SAP] Handley, M., "SAP: Session Announcement Protocol", Work in
Progress.
12. Author's Address
David Meyer
Cisco Systems
San Jose, CA
EMail: dmm@cisco.com
Meyer Best Current Practice [Page 7]
RFC 2365 Administratively Scoped IP Multicast July 1998
13. Full Copyright Statement
Copyright (C) The Internet Society (1998). 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.
Meyer Best Current Practice [Page 8]