As per Relevance of the word boundary, we have this rfc below:
Network Working Group D.
Request for Comments: 2365 University of
BCP: 23 July 1998
Category: Best Current
Administratively Scoped IP
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
1.
This document defines the "administratively scoped IPv4
space" to be the range 239.0.0.0 to 239.255.255.255. In addition,
describes a simple set of semantics for the implementation
Administratively Scoped IP Multicast. Finally, it provides a
between the IPv6 multicast address classes [RFC1884] and IPv
multicast address classes
This memo is a product of the MBONE Deployment Working Group (MBONED
in the Operations and Management Area of the Internet
Task Force. Submit comments to or the author
2.
Much of this memo is taken from "Administratively Scoped
Multicast", Van Jacobson and Steve Deering, presented at the 30
IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley
Dave Thaler have also provided insightful comments on
versions of this document
3.
Most current IP multicast implementations achieve some level
scoping by using the TTL field in the IP header. Typical
(Multicast Backbone) usage has been to engineer TTL thresholds
confine traffic to some administratively defined topological region
The basic forwarding rule for interfaces with configured
thresholds is that a packet is not forwarded across the
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
traffic with the objective of easing stress on scarce
(e.g., bandwidth), or to achieve some kind of improved privacy
scaling properties. In addition, the TTL is also used in
traditional role to limit datagram lifetime. Given these
conflicting roles, TTL scoping has proven difficult to
reliably, and the resulting schemes have often been complex
difficult to understand
A more serious architectural problem concerns the interaction of
scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]).
particular problem is that in many common cases, TTL scoping
prevent pruning from being effective. Consider the case in which
packet has either had its TTL expire or failed a TTL threshold.
router which discards the packet will not be capable of pruning
upstream sources, and thus will sink all multicast traffic (
or not there are downstream receivers). Note that while it might
possible to send prunes upstream from the point at which a packet
discarded, this strategy can result in legitimate traffic
discarded, since subsequent packets could take a different path
arrive at the same point with a larger TTL
On the other hand, administratively scoped IP multicast can
clear and simple semantics for scoped IP multicast. The
properties of administratively scoped IP multicast are that (i).
packets addressed to administratively scoped multicast addresses
not cross configured administrative boundaries, and (ii).
administratively scoped multicast addresses are locally assigned,
hence are not required to be unique across administrative boundaries
4. Definition of the Administratively Scoped IPv4 Multicast
The administratively scoped IPv4 multicast address space is
to be the range 239.0.0.0 to 239.255.255.255.
5.
In order to support administratively scoped IP multicast, a
should support the configuration of per-interface scoped IP
boundaries. Such a router, called a boundary router, does not
packets matching an interface's boundary definition in
direction (the bi-directional check prevents problems with multi
access networks). In addition, a boundary router always prunes
boundary for dense-mode groups [PIMDM], and doesn't accept joins
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
The structure of the IP version 4 administratively scoped
space is loosely based on the IP Version 6 Addressing
described in RFC 1884 [RFC1884]. This document defines two
scopes: the IPv4 Local Scope and IPv4 Organization Local Scope.
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
Scope is the minimal enclosing scope, and hence is not
divisible. Although the exact extent of a Local Scope is
dependent, locally scoped regions must obey certain
constraints. In particular, a Local Scope must not span any
scope boundary. Further, a Local Scope must be completely
within or equal to any larger scope. In the event that scope
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
Scope. The more general topological requirements for
scoped regions are discussed below
6.1.1. Expansion of the IPv4 Local
The IPv4 Local Scope space grows "downward". As such, the IPv4
Scope may grow downward from 239.255.0.0/16 into the reserved
239.254.0.0/16 and 239.253.0.0/16. However, these ranges should
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
The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10
unassigned and available for expansion of this space. These
should be left unassigned until the 239.192.0.0/14 space is no
sufficient. This is to allow for the possibility that
revisions of this document may define additional scopes on a
larger than organizations
6.3. Other IPv4 Scopes of
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.
existing static global scope allocations are somewhat more granular
and
224.1.0.0-224.1.255.255 ST Multicast
224.2.0.0-224.2.127.253 Multimedia Conference
224.2.127.254 SAPv1
224.2.127.255 SAPv0 Announcements (deprecated
224.2.128.0-224.2.255.255 SAP Dynamic
224.252.0.0-224.255.255.255 DIS transient
232.0.0.0-232.255.255.255 VMTP transient
See [RFC1700] for current multicast address assignments (this
can also be found, possibly in a more current form,
ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses).
7. Topological Requirements for Administrative
An administratively scoped IP multicast region is defined to be
topological region in which there are one or more boundary
with common boundary definitions. Such a router is said to be
boundary for scoped addresses in the range defined in
configuration
Network administrators may configure a scope region
constrained multicast scope is required. In addition,
administrator may configure overlapping scope regions (networks
be in multiple scope regions) where convenient, with the
limitations being that a scope region must be connected (there
be a path between any two nodes within a scope region that doesn'
leave that region), and convex (i.e., no path between any two
in the region can cross a region boundary). However, it is
to note that if administratively scoped areas
topologically, then the outer scope must consist of its address
minus the address spaces of any intersecting scopes. This
prevents the problem that would arise when a path between two
in a convex region crosses the boundary of an intersecting region
For this reason, it is recommended that administrative scopes
intersect topologically should not intersect in address range
Finally, note that any scope boundary is a boundary for the
Scope. This implies that packets sent to groups covered
239.255.0.0/16 must not be forwarded across any link for which
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
The following table outlines the partitioning of the IPv4
space, and gives the mapping from IPv4 multicast prefixes to IPv
SCOP values
IPv6 SCOP RFC 1884 Description IPv4
===============================================================
0
1 node-local
2 link-local scope 224.0.0.0/24
3 (unassigned) 239.255.0.0/16
4 (unassigned
5 site-local
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
(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
The high order /24 in every scoped region is reserved for
assignments. A relative assignment is an integer offset from
address in the scope and represents a 32-bit address (for IPv4).
example, in the Local Scope defined above, 239.255.255.0/24
reserved for relative allocations. The de-facto relative
"0", (i.e., 239.255.255.255 in the Local Scope) currently exists
SAP [SAP]. The next relative assignment, "1", corresponds to
address 239.255.255.254 in the Local Scope. The rest of a
region below the reserved /24 is available for dynamic
(presumably by an address allocation protocol).
In is important to note that a scope discovery protocol [MZAP]
have to be developed to make practical use of scopes other than
Local Scope. In addition, since any use of any
scoped region, including the Local Scope, requires
assigned addressing, an Address Allocation Protocol (AAP) will
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
Requests for relative assignments should be directed to the IANA.
IANA will be advised by an area expert when making relative
assignments. The area expert will be appointed by the relevant
Director
In general, relative addresses will be used only for bootstrapping
dynamic address assignments from within the scope. As such,
assignments should only be made to those services that cannot use
dynamic address assignment protocol to find the address used by
service within the desired scope, such as a dynamic
assignment service itself
10. Security
It is recommended that organizations using the
scoped IP Multicast addresses not rely on them to prevent
data from being transmitted outside the organization. Should
multicast router on an administrative boundary be mis-configured
have a bug in the administrative scoping code, or have other
that would cause that router to forward an administratively scoped
multicast packet outside of the proper scope, the organizations
would leave its intended transmission region
Organizations using administratively scoped IP Multicasting
transmit sensitive data should use some confidentiality
(e.g. encryption) to protect that data. In the case of many
video-conferencing applications (e.g. vat), encryption is
as an application feature and merely needs to be enabled (
appropriate cryptographic keys securely distributed). For many
applications, the use of the IP Encapsulating Security Payload (ESP
[RFC-1825, RFC-1827] can provide IP-layer confidentiality
encryption
Within the context of an administratively scoped IP multicast group
the use of manual key distribution might well be feasible.
dynamic key management for IP Security is a research area at the
this note is written, it is expected that the IETF will be
the ISAKMP key management protocol to support scalable multicast
distribution in the future
It is important to note that the "boundary router" described in
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.
[ASMA] V. Jacobson, S. Deering, "Administratively Scoped
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
(MZAP)", Work in Progress
[PIMDM] Deering, S, et. al., "Protocol Independent
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,
1700, October 1994.
[RFC1884] Hinden. R., and S. Deering, "IP Version 6
Architecture", RFC1884, December 1995.
[SAP] Handley, M., "SAP: Session Announcement Protocol", Work
Progress
12. Author's
David
Cisco
San Jose,
EMail: dmm@cisco.
Meyer Best Current Practice [Page 7]
RFC 2365 Administratively Scoped IP Multicast July 1998
13. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Meyer Best Current Practice [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
