draft-ietf-mboned-mcaddrdoc-03.txt   draft-ietf-mboned-mcaddrdoc-04.txt 
Network Working Group S. Venaas Network Working Group S. Venaas
Internet-Draft R. Parekh Internet-Draft R. Parekh
Intended status: Informational G. Van de Velde Intended status: Informational G. Van de Velde
Expires: August 12, 2012 cisco Systems Expires: November 18, 2012 cisco Systems
T. Chown T. Chown
University of Southampton University of Southampton
M. Eubanks M. Eubanks
Iformata Communications Iformata Communications
February 9, 2012 May 17, 2012
Multicast Addresses for Documentation Multicast Addresses for Documentation
draft-ietf-mboned-mcaddrdoc-03.txt draft-ietf-mboned-mcaddrdoc-04.txt
Abstract Abstract
This document discusses which multicast addresses should be used for This document discusses which multicast addresses should be used for
documentation purposes and reserves multicast addresses for such use. documentation purposes and reserves multicast addresses for such use.
Some multicast addresses are derived from AS numbers or unicast Some multicast addresses are derived from AS numbers or unicast
addresses. This document also explains how these can be used for addresses. This document also explains how these can be used for
documentation purposes. documentation purposes.
Status of this Memo Status of this Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 12, 2012. This Internet-Draft will expire on November 18, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 42 skipping to change at page 4, line 42
integer offset from the highest address in the scope and represents integer offset from the highest address in the scope and represents
an IPv4 address. For documentation purposes, the integer offset is an IPv4 address. For documentation purposes, the integer offset is
TBD1. This provides one multicast address per scope. TBD1. This provides one multicast address per scope.
For example in the Local Scope 239.255.0.0/16, the multicast address For example in the Local Scope 239.255.0.0/16, the multicast address
for documentation purposes is 239.255.255.255-TBD1. for documentation purposes is 239.255.255.255-TBD1.
2.2. GLOP multicast addresses 2.2. GLOP multicast addresses
GLOP [RFC3180] is a method for deriving IPv4 multicast group GLOP [RFC3180] is a method for deriving IPv4 multicast group
addresses from 16 bit AS numbers. For examples where GLOP addresses addresses from 16-bit AS numbers. For examples where GLOP addresses
are desired, the addresses should be derived from the AS numbers are desired, the addresses should be derived from the AS numbers
reserved for documentation use. reserved for documentation use.
The 16 bit AS numbers reserved for documentation use in [RFC5398] are The 16-bit AS numbers reserved for documentation use in [RFC5398] are
64496 - 64511. By use of [RFC3180], we then get 16 /24 multicast 64496 - 64511. By use of [RFC3180], we then get 16 /24 multicast
prefixes for documentation use. The first one 233.251.240.0/24, and prefixes for documentation use. The first one 233.251.240.0/24, and
the last 233.251.255.0/24. the last 233.251.255.0/24.
2.3. Unicast prefix based IPv4 multicast addresses 2.3. Unicast prefix based IPv4 multicast addresses
IPv4 multicast addresses can be derived from IPv4 unicast prefixes, IPv4 multicast addresses can be derived from IPv4 unicast prefixes,
see [RFC6034]. For examples where this type of addresses are see [RFC6034]. For examples where this type of addresses are
desired, the addresses should be derived from the unicast addresses desired, the addresses should be derived from the unicast addresses
reserved for documentation purposes, see [RFC5737]. reserved for documentation purposes, see [RFC5737].
There are three unicast address ranges provided for documentation use There are three unicast address ranges provided for documentation use
in [RFC5737]. The ranges are 192.0.2.0/24, 198.51.100.0/24 and in [RFC5737]. The ranges are 192.0.2.0/24, 198.51.100.0/24 and
203.0.113.0/24. Using [RFC6034] this leaves us with the unicast 203.0.113.0/24. Using [RFC6034] this leaves us with the unicast
prefix based IPv4 multicast addresses 234.192.0.2, 234.198.51.100 and prefix based IPv4 multicast addresses 234.192.0.2, 234.198.51.100 and
234.203.0.113. 234.203.0.113.
3. IPv6 multicast documentation addresses 3. IPv6 multicast documentation addresses
For Any-Source Multicast (ASM) the IPv6 multicast addresses allocated For Any-Source Multicast (ASM) the IPv6 multicast addresses allocated
for documentation purposes are TBD2. 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
[RFC3307]). Also note that for these addresses the transient flag,
the T-flag as defined in [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.
For Source-Specific Multicast (SSM) it is less important which For Source-Specific Multicast (SSM) it is less important which
multicast addresses are used, since a host/application joins a multicast addresses are used, since a host/application joins a
channel identified by both source and group. Any source addresses channel identified by both source and group. Any source addresses
used in SSM examples should be unicast addresses reserved for used in SSM examples should be unicast addresses reserved for
documentation purposes. The IPv6 unicast prefix reserved for documentation purposes. The IPv6 unicast prefix reserved for
documentation purposes is 2001:DB8::/32, see [RFC3849]. documentation purposes is 2001:DB8::/32, see [RFC3849].
Sometimes one wants to give examples where a specific type of address Sometimes one wants to give examples where a specific type of address
is desired. E.g. for text about multicast scoping, one might want is desired. E.g. for text about multicast scoping, one might want
skipping to change at page 8, line 8 skipping to change at page 8, line 8
the range 2001:DB8::/32 that follows the constraints specified in the range 2001:DB8::/32 that follows the constraints specified in
[RFC3956]. One example address could be 2001:DB8::1. The [RFC3956]. One example address could be 2001:DB8::1. The
embedded-RP multicast prefixes might then be FF7X:120:2001:DB8::/96. 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 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 gives the prefixes FF7X:740:2001:DB8:BEEF:FEED::/96. See also the
examples in [RFC3956]. examples in [RFC3956].
4. Security Considerations 4. Security Considerations
The use of specific multicast addresses for documentation purposes The use of specific multicast addresses for documentation purposes
has no impact on security. has no negative impact on security.
5. IANA Considerations 5. IANA Considerations
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.
IANA is requested to assign a scope relative IPv4 address for IANA is requested to assign a scope relative IPv4 address for
documentation purposes. The string TBD1 in this document should be documentation purposes.
replaced by the assigned offset. Also the string 255-TBD1 should be
replaced by the value of 255 minus the assigned offset. These last This paragraph contains some further instructions for IANA in order
two sentences should be deleted before publishing. 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.
IANA is requested to assign "variable scope" IPv6 multicast addresses IANA is requested to assign "variable scope" IPv6 multicast addresses
for documentation purposes. This should be a /96 prefix of the form for documentation purposes. This should be a /96 prefix.
FF0X:... The word TBD2 in this text should be replaced with the
assigned prefix, and this sentence should be deleted before This paragraph contains some further instructions for IANA in order
publishing. 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.
6. Acknowledgments 6. Acknowledgments
The authors thank Roberta Maglione, Leonard Giuliano and Dave Thaler The authors thank Roberta Maglione, Leonard Giuliano and Dave Thaler
for providing comments on this document. for providing comments on this document.
7. Informative References 7. Informative References
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998. RFC 2365, July 1998.
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8",
BCP 53, RFC 3180, September 2001. BCP 53, RFC 3180, September 2001.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002. Multicast Addresses", RFC 3306, August 2002.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002. Addresses", RFC 3307, August 2002.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004. Reserved for Documentation", RFC 3849, July 2004.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004. RFC 3956, November 2004.
[RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for
Documentation Use", RFC 5398, December 2008. Documentation Use", RFC 5398, December 2008.
 End of changes. 12 change blocks. 
16 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/