One document matched: draft-ietf-mboned-mcaddrdoc-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<rfc category="info" ipr="trust200902"
docName="draft-ietf-mboned-mcaddrdoc-04.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>Multicast Addresses for Documentation</title>
<author initials='S.' surname='Venaas' fullname='Stig Venaas'>
<organization>cisco Systems</organization>
<address><postal>
<street>Tasman Drive</street>
<city>San Jose</city> <region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>stig@cisco.com</email></address>
</author>
<author initials='R.' surname='Parekh' fullname='Rishabh Parekh'>
<organization>cisco Systems</organization>
<address><postal>
<street>Tasman Drive</street>
<city>San Jose</city> <region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>riparekh@cisco.com</email></address>
</author>
<author initials="G." surname="Van de Velde" fullname="Gunter Van de Velde">
<organization>cisco Systems</organization>
<address>
<postal>
<street>De Kleetlaan 6a</street>
<city>Diegem</city>
<country>Belgium</country>
<code>1831</code>
</postal>
<phone>+32 476 476 022</phone>
<email>gvandeve@cisco.com</email>
</address>
</author>
<author fullname="Tim Chown" initials="T.J." surname="Chown">
<organization> University of Southampton </organization>
<address>
<postal>
<street> Highfield </street>
<city> Southampton </city>
<code> SO17 1BJ </code>
<region> Hampshire </region>
<country> United Kingdom </country>
</postal>
<email> tjc@ecs.soton.ac.uk </email>
</address>
</author>
<author fullname="Marshall Eubanks" initials="M."
surname="Eubanks">
<organization>Iformata Communications</organization>
<address>
<postal>
<street>130 W. Second Street</street>
<city>Dayton</city>
<region>Ohio</region>
<code>45402</code>
<country>US</country>
</postal>
<phone>+1 703 501 4376</phone>
<email>marshall.eubanks@iformata.com</email>
<uri>http://www.iformata.com/</uri>
</address>
</author>
<date/>
<abstract>
<t>This document discusses which multicast addresses should be used for
documentation purposes and reserves multicast addresses for such
use. Some multicast addresses are derived from
AS numbers or unicast addresses. This document also explains how
these can be used for documentation purposes.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>It is often useful in documentation, IETF documents, etc.,
to provide examples containing IP multicast addresses.
For documentation where examples of general purpose multicast addresses
are needed, one should use multicast addresses that never will be
assigned or in actual use. There is a risk that addresses used in
examples may accidentally be used. It is then important that the
same addresses are not used by other multicast applications or
services. It may also be beneficial to filter out such addresses
from multicast signalling and multicast data sent to such addresses.
</t><t>
For unicast there are both IPv4 and IPv6 addresses
reserved for this purpose,
see <xref target="RFC5737"/> and <xref target="RFC3849"/>
respectively. This document reserves multicast addresses for this
purpose.
</t>
<t>There are also some multicast addresses that are derived from AS
numbers or unicast addresses. For examples where such addresses are
desired, one should derive them from the AS numbers and unicast
addresses reserved for documentation purposes. This document also
discusses the use of these.
</t>
</section>
<section title="IPv4 multicast documentation addresses">
<t>
For Any-Source Multicast (ASM), the IPv4 multicast addresses allocated
for documentation purposes
are 233.252.0.0 - 233.252.0.255 (233.252.0.0/24).
</t>
<t>
For Source-Specific Multicast (SSM) it is less important which multicast
addresses are used, since
a host/application joins a channel identified by both source and
group. Any source addresses used in SSM examples should be unicast
addresses reserved for documentation purposes. There are three
unicast address ranges provided for documentation use in
<xref target="RFC5737"/>. The ranges are 192.0.2.0/24,
198.51.100.0/24 and 203.0.113.0/24.
</t>
<t>Sometimes one wants to give examples where a specific
type of address is desired. E.g. for text about multicast scoping,
one might want the examples to use addresses that are to be used for
administrative scoping. See below for guidance on how to construct
specific types of example addresses.</t>
<section title="Administratively scoped IPv4 multicast addresses">
<t>Administratively scoped IPv4 multicast addresses
<xref target="RFC2365"/> are reserved for scoped multicast. They can
be used within a site or an organization. Apart from a small set of
scope relative addresses, these addresses are not assigned. The high
order /24 in every scope is reserved for relative assignments.
A relative assignment is an integer offset from the highest address in
the scope and represents an IPv4 address. For documentation
purposes, the integer offset is TBD1. This provides one multicast address
per scope.
</t><t>
For example in the Local Scope 239.255.0.0/16, the multicast address
for documentation purposes is 239.255.255.255-TBD1.</t>
</section>
<section title="GLOP multicast addresses">
<t>GLOP <xref target="RFC3180"/> is a method for deriving IPv4 multicast
group addresses from 16-bit AS numbers. For examples where GLOP
addresses are desired, the addresses should be
derived from the AS numbers reserved for documentation use.
</t>
<t>The 16-bit AS numbers reserved for documentation use in
<xref target="RFC5398"/> are 64496 - 64511. By use of
<xref target="RFC3180"/>, we then get 16 /24 multicast prefixes
for documentation use. The first
one 233.251.240.0/24, and the last 233.251.255.0/24.</t>
</section>
<section title="Unicast prefix based IPv4 multicast addresses">
<t>IPv4 multicast addresses can be derived from IPv4 unicast prefixes,
see <xref target="RFC6034"/>. For examples where this type of addresses
are desired, the addresses should be derived from the unicast addresses
reserved for documentation purposes, see <xref target="RFC5737"/>.
</t>
<t>There are three unicast address ranges provided for documentation use
in <xref target="RFC5737"/>. The ranges are 192.0.2.0/24, 198.51.100.0/24
and 203.0.113.0/24. Using <xref target="RFC6034"/> this leaves us with
the unicast prefix based IPv4 multicast addresses 234.192.0.2,
234.198.51.100 and 234.203.0.113.</t>
</section>
</section>
<section title="IPv6 multicast documentation addresses">
<t>
For Any-Source Multicast (ASM) the IPv6 multicast addresses allocated
for documentation purposes are TBD2. This is a /96 prefix so that it
can be used with group IDs according to the allocation guidelines in
<xref target="RFC3307"/>). Also note that for these addresses the
transient flag, the T-flag as defined in <xref target="RFC3513"/>, is
zero. This is because they are permanently assigned. There can be no
permanently assigned addresses for documentation purposes with the
transient flag set to one, since the flag set to one means that they
are not permanently assigned.
</t>
<t>
For Source-Specific Multicast (SSM) it is less important which multicast
addresses are used, since
a host/application joins a channel identified by both source and
group. Any source addresses used in SSM examples should be unicast
addresses reserved for documentation purposes. The IPv6 unicast
prefix reserved for documentation purposes is 2001:DB8::/32,
see <xref target="RFC3849"/>.
</t>
<t>Sometimes one wants to give examples where a specific
type of address is desired. E.g. for text about multicast scoping,
one might want the examples to use addresses that are to be used for
administrative scoping. See below for guidance on how to construct
specific types of example addresses.</t>
<section title="Unicast prefix based IPv6 multicast addresses">
<t>IPv6 multicast addresses can be derived from IPv6 unicast prefixes,
see <xref target="RFC3306"/>. For examples where this type of addresses
is desired, the addresses should be derived from the unicast addresses
reserved for documentation purposes.
</t>
<t>The IPv6 unicast prefix reserved for documentation purposes is
2001:DB8::/32, see <xref target="RFC3849"/>.
This allows a wide range of different IPv6 multicast addresses. Using
just the base /32 prefix, one gets the IPv6 multicast prefixes
FF3X:20:2001:DB8::/64, one for each available scope X. One can also
produce longer prefixes from this. Just as an example, one can pick
say a /64 prefix 2001:DB8:DEAD:BEEF::/64 which gives the multicast
prefixes FF3X:40:2001:DB8:DEAD:BEEF::/96, one for each available scope X.
</t>
</section>
<section title="Embedded-RP IPv6 multicast addresses">
<t>There is a type of IPv6 multicast addresses called Embedded-RP
addresses where the IPv6 address of a Rendezvous-Point is embedded
inside the multicast address, see <xref target="RFC3956"/>.
For examples where this type of addresses is desired, the addresses should
be derived from the unicast addresses reserved for documentation purposes,
see <xref target="RFC3849"/>.
</t><t>
For documentation purposes, the RP address can be any address from the
range 2001:DB8::/32 that follows the constraints specified
in <xref target="RFC3956"/>. One example address could be 2001:DB8::1.
The embedded-RP multicast prefixes might then be
FF7X:120:2001:DB8::/96. Another example could be the RP address
2001:DB8:BEEF:FEED::7 which gives the prefixes
FF7X:740:2001:DB8:BEEF:FEED::/96. See also the examples in
<xref target="RFC3956"/>.</t>
</section>
</section>
<section title="Security Considerations">
<t>
The use of specific multicast addresses for documentation purposes has no
negative impact on security.
</t>
</section>
<section title="IANA Considerations">
<t>IANA is requested to add a reference to this document for the
IPv4 MCAST-TEST-NET allocation, so that all the different documentation
multicast assignments reference this document.</t>
<t>IANA is requested to assign a scope relative IPv4 address for
documentation purposes.</t>
<t>This paragraph contains some further instructions for IANA in order to
clarify. It should be deleted before publishing. The string TBD1 in this
document should be replaced by the assigned offset. Also the string
255-TBD1 should be replaced by the value of 255 minus the assigned offset.
The next available offset seems currently to be 10. Look in the registry
for where it says "10-252 Reserved - To be assigned by the IANA". If the
value 10 is chosen, then we would like to add
"10 MCAST-TEST-NET-2 [RFCxxxx]" to
the table. TBD1 would then be 10. TBD1 is used in two places apart from
the IANA considerations. In one place it says just TBD1, that should
be replaced by "10". The other place it says "239.255.255.255-TBD1".
That should then be replaced by "239.255.255.245". In the unlikely
event that 10 is not available, please use the first available value
accordingly. MCAST-TEST-NET-2 is suggested here, since the existing
allocation is named MCAST-TEST-NET.</t>
<t>IANA is requested to assign "variable scope" IPv6 multicast addresses
for documentation purposes. This should be a /96 prefix.</t>
<t>This paragraph contains some further instructions for IANA in order to
clarify. It should be deleted before publishing. The word TBD2 in this
text should be replaced with the assigned prefix. The prefix should be
of the form FF0X:.../96. In order to make this documentation prefix easily
recognizable, the authors would like to request the prefix
FF0X::DB8:0:0/96 if possible. This makes it somewhat similar to the IPv6
unicast prefix 2001:DB8::/32. We suggest they are denoted as
"Documentation Addresses" with a reference to this document.
</t>
</section>
<section title="Acknowledgments">
<t>The authors thank Roberta Maglione, Leonard Giuliano and
Dave Thaler
for providing comments on this document.</t>
</section>
</middle>
<back>
<references title='Informative References'>
<?rfc include='reference.RFC.2365' ?>
<?rfc include='reference.RFC.3180' ?>
<?rfc include='reference.RFC.3306' ?>
<?rfc include='reference.RFC.3307' ?>
<?rfc include='reference.RFC.3513' ?>
<?rfc include='reference.RFC.3849' ?>
<?rfc include='reference.RFC.3956' ?>
<?rfc include='reference.RFC.5398' ?>
<?rfc include='reference.RFC.5737' ?>
<?rfc include='reference.RFC.6034' ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:29:59 |