Diff: draft-ietf-mboned-mcaddrdoc-04.txt

	draft-ietf-mboned-mcaddrdoc-04.txt	rfc6676.txt


	Network Working Group S. Venaas	Internet Engineering Task Force (IETF) S. Venaas
	Internet-Draft R. Parekh	Request for Comments: 6676 R. Parekh
	Intended status: Informational G. Van de Velde	Category: Informational G. Van de Velde
	Expires: November 18, 2012 cisco Systems	ISSN: 2070-1721 Cisco Systems
	T. Chown	T. Chown
	University of Southampton	University of Southampton
	M. Eubanks	M. Eubanks
	Iformata Communications	Iformata Communications

	May 17, 2012	August 2012

	Multicast Addresses for Documentation	Multicast Addresses for Documentation

	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

	This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.


	Internet-Drafts are working documents of the Internet Engineering	This document is not an Internet Standards Track specification; it is
	Task Force (IETF). Note that other groups may also distribute	published for informational purposes.
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.


	Internet-Drafts are draft documents valid for a maximum of six months	This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any	(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference	received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."	Internet Engineering Steering Group (IESG). Not all documents
		approved by the IESG are a candidate for any level of Internet
		Standard; see Section 2 of RFC 5741.


	This Internet-Draft will expire on November 18, 2012.	Information about the current status of this document, any errata,
		and how to provide feedback on it may be obtained at
		http://www.rfc-editor.org/info/rfc6676.

	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
	carefully, as they describe your rights and restrictions with respect	carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must	to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of	include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as	the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.	described in the Simplified BSD License.

	Table of Contents	Table of Contents


	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction ....................................................2
	2. IPv4 multicast documentation addresses . . . . . . . . . . . . 4	2. IPv4 Multicast Documentation Addresses ..........................3
	2.1. Administratively scoped IPv4 multicast addresses . . . . . 4	2.1. Administratively Scoped IPv4 Multicast Addresses ...........3
	2.2. GLOP multicast addresses . . . . . . . . . . . . . . . . . 4	2.2. GLOP Multicast Addresses ...................................3
	2.3. Unicast prefix based IPv4 multicast addresses . . . . . . 5	2.3. Unicast Prefix-Based IPv4 Multicast Addresses ..............4
	3. IPv6 multicast documentation addresses . . . . . . . . . . . . 6	3. IPv6 Multicast Documentation Addresses ..........................4
	3.1. Unicast prefix based IPv6 multicast addresses . . . . . . 6	3.1. Unicast Prefix-Based IPv6 Multicast Addresses ..............5
	3.2. Embedded-RP IPv6 multicast addresses . . . . . . . . . . . 6	3.2. Embedded-RP IPv6 Multicast Addresses .......................5
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8	4. Security Considerations .........................................5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9	5. IANA Considerations .............................................5
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10	6. Acknowledgments .................................................6
	7. Informative References . . . . . . . . . . . . . . . . . . . . 11	7. Informative References ..........................................6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

	1. Introduction	1. Introduction

	It is often useful in documentation, IETF documents, etc., to provide	It is often useful in documentation, IETF documents, etc., to provide
	examples containing IP multicast addresses. For documentation where	examples containing IP multicast addresses. For documentation where
	examples of general purpose multicast addresses are needed, one	examples of general purpose multicast addresses are needed, one

	should use multicast addresses that never will be assigned or in	should use multicast addresses that will never be assigned or in
	actual use. There is a risk that addresses used in examples may	actual use. There is a risk that addresses used in examples may
	accidentally be used. It is then important that the same addresses	accidentally be used. It is then important that the same addresses

	are not used by other multicast applications or services. It may	not be used by other multicast applications or services. It may also
	also be beneficial to filter out such addresses from multicast	be beneficial to filter out such addresses from multicast signalling
	signalling and multicast data sent to such addresses.	and to filter out multicast data sent to such addresses.


	For unicast there are both IPv4 and IPv6 addresses reserved for this	For unicast, there are both IPv4 and IPv6 addresses reserved for this
	purpose, see [RFC5737] and [RFC3849] respectively. This document	purpose; see [RFC5737] and [RFC3849], respectively. This document
	reserves multicast addresses for this purpose.	reserves multicast addresses for this same purpose.

	There are also some multicast addresses that are derived from AS	There are also some multicast addresses that are derived from AS
	numbers or unicast addresses. For examples where such addresses are	numbers or unicast addresses. For examples where such addresses are
	desired, one should derive them from the AS numbers and unicast	desired, one should derive them from the AS numbers and unicast
	addresses reserved for documentation purposes. This document also	addresses reserved for documentation purposes. This document also
	discusses the use of these.	discusses the use of these.


	2. IPv4 multicast documentation addresses	2. IPv4 Multicast Documentation Addresses

	For Any-Source Multicast (ASM), the IPv4 multicast addresses	For Any-Source Multicast (ASM), the IPv4 multicast addresses
	allocated for documentation purposes are 233.252.0.0 - 233.252.0.255	allocated for documentation purposes are 233.252.0.0 - 233.252.0.255
	(233.252.0.0/24).	(233.252.0.0/24).


	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. There are three unicast address ranges	documentation purposes. There are three unicast address ranges
	provided for documentation use in [RFC5737]. The ranges are	provided for documentation use in [RFC5737]. The ranges are
	192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24.	192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24.

	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. For example, for text about multicast scoping, one might
	the examples to use addresses that are to be used for administrative	want the examples to use addresses that are to be used for
	scoping. See below for guidance on how to construct specific types	administrative scoping. See below for guidance on how to construct
	of example addresses.	specific types of example addresses.


	2.1. Administratively scoped IPv4 multicast addresses	2.1. Administratively Scoped IPv4 Multicast Addresses

	Administratively scoped IPv4 multicast addresses [RFC2365] are	Administratively scoped IPv4 multicast addresses [RFC2365] are
	reserved for scoped multicast. They can be used within a site or an	reserved for scoped multicast. They can be used within a site or an

	organization. Apart from a small set of scope relative addresses,	organization. Apart from a small set of scope-relative addresses,
	these addresses are not assigned. The high order /24 in every scope	these addresses are not assigned. The high order /24 in every scope
	is reserved for relative assignments. A relative assignment is an	is reserved for relative assignments. A relative assignment is an
	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.	10. 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.245.


	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 is 233.251.240.0/24,
	the last 233.251.255.0/24.	and the last one is 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 address is desired,
	desired, the addresses should be derived from the unicast addresses	the addresses should be derived from the unicast addresses reserved
	reserved for documentation purposes, see [RFC5737].	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 the unicast prefix-
	prefix based IPv4 multicast addresses 234.192.0.2, 234.198.51.100 and	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
	for documentation purposes are TBD2. This is a /96 prefix so that it	allocated for documentation purposes are FF0X::DB8:0:0/96. This is a
	can be used with group IDs according to the allocation guidelines in	/96 prefix so that it can be used with group IDs, according to the
	[RFC3307]). Also note that for these addresses the transient flag,	allocation guidelines in [RFC3307]. Also note that for these
	the T-flag as defined in [RFC3513], is zero. This is because they	addresses, the transient flag, or "T-flag" as defined in [RFC4291],
	are permanently assigned. There can be no permanently assigned	is zero. This is because they are permanently assigned. There can
	addresses for documentation purposes with the transient flag set to	be no permanently assigned addresses for documentation purposes with
	one, since the flag set to one means that they are not permanently	the transient flag set to one, since the flag set to one means that
	assigned.	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. For example, for text about multicast scoping, one might
	the examples to use addresses that are to be used for administrative	want the examples to use addresses that are to be used for
	scoping. See below for guidance on how to construct specific types	administrative scoping. See below for guidance on how to construct
	of example addresses.	specific types of example addresses.


	3.1. Unicast prefix based IPv6 multicast addresses	3.1. Unicast Prefix-Based IPv6 Multicast Addresses

	IPv6 multicast addresses can be derived from IPv6 unicast prefixes,	IPv6 multicast addresses can be derived from IPv6 unicast prefixes,

	see [RFC3306]. For examples where this type of addresses is desired,	see [RFC3306]. For examples where this type of address is desired,
	the addresses should be derived from the unicast addresses reserved	the addresses should be derived from the unicast addresses reserved
	for documentation purposes.	for documentation purposes.

	The IPv6 unicast prefix reserved for documentation purposes is 2001:	The IPv6 unicast prefix reserved for documentation purposes is 2001:
	DB8::/32, see [RFC3849]. This allows a wide range of different IPv6	DB8::/32, see [RFC3849]. This allows a wide range of different IPv6
	multicast addresses. Using just the base /32 prefix, one gets the	multicast addresses. Using just the base /32 prefix, one gets the

	IPv6 multicast prefixes FF3X:20:2001:DB8::/64, one for each available	IPv6 multicast prefixes FF3X:20:2001:DB8::/64 -- one for each
	scope X. One can also produce longer prefixes from this. Just as an	available scope X. One can also produce longer prefixes from this.
	example, one can pick say a /64 prefix 2001:DB8:DEAD:BEEF::/64 which	Just as an example, one can pick a /64 prefix 2001:DB8:DEAD:
	gives the multicast prefixes FF3X:40:2001:DB8:DEAD:BEEF::/96, one for	BEEF::/64, which gives the multicast prefixes FF3X:40:2001:DB8:DEAD:
	each available scope X.	BEEF::/96 -- one for each available scope X.

	3.2. Embedded-RP IPv6 multicast addresses


	There is a type of IPv6 multicast addresses called Embedded-RP	3.2. Embedded-RP IPv6 Multicast Addresses
	addresses where the IPv6 address of a Rendezvous-Point is embedded
	inside the multicast address, see [RFC3956]. For examples where this
	type of addresses is desired, the addresses should be derived from
	the unicast addresses reserved for documentation purposes, see


	[RFC3849].	There is a type of IPv6 multicast address called an "Embedded-RP"
		address, where the IPv6 address of a Rendezvous-Point (RP) is
		embedded inside the multicast address, see [RFC3956]. For examples
		where this type of address is desired, the addresses should be
		derived from the unicast addresses reserved for documentation
		purposes, see [RFC3849].

	For documentation purposes, the RP address can be any address from	For documentation purposes, the RP address can be any address from
	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 negative 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	IANA has added a reference to this document for the IPv4 MCAST-TEST-
	MCAST-TEST-NET allocation, so that all the different documentation	NET allocation so that all the different documentation multicast
	multicast assignments reference this document.	assignments reference this document.

	IANA is requested to assign a scope relative IPv4 address for
	documentation purposes.

	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.


	IANA is requested to assign "variable scope" IPv6 multicast addresses	IANA has assigned a scope-relative IPv4 address for documentation
	for documentation purposes. This should be a /96 prefix.	purposes.


	This paragraph contains some further instructions for IANA in order	IANA has assigned "variable-scope" IPv6 multicast addresses for
	to clarify. It should be deleted before publishing. The word TBD2	documentation purposes. This is a /96 prefix.
	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.


		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
		Architecture", RFC 4291, February 2006.

	[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.

	[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks	[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
	Reserved for Documentation", RFC 5737, January 2010.	Reserved for Documentation", RFC 5737, January 2010.

	[RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast	[RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast
	Addresses", RFC 6034, October 2010.	Addresses", RFC 6034, October 2010.

	Authors' Addresses	Authors' Addresses

	Stig Venaas	Stig Venaas

	cisco Systems	Cisco Systems
	Tasman Drive	Tasman Drive
	San Jose, CA 95134	San Jose, CA 95134
	USA	USA

		EMail: stig@cisco.com
	Email: stig@cisco.com

	Rishabh Parekh	Rishabh Parekh

	cisco Systems	Cisco Systems
	Tasman Drive	Tasman Drive
	San Jose, CA 95134	San Jose, CA 95134
	USA	USA

		EMail: riparekh@cisco.com
	Email: riparekh@cisco.com

	Gunter Van de Velde	Gunter Van de Velde

	cisco Systems	Cisco Systems
	De Kleetlaan 6a	De Kleetlaan 6a
	Diegem 1831	Diegem 1831
	Belgium	Belgium


	Phone: +32 476 476 022	Phone: +32 476 476 022

	Email: gvandeve@cisco.com	EMail: gvandeve@cisco.com

	Tim Chown	Tim Chown
	University of Southampton	University of Southampton
	Highfield	Highfield
	Southampton, Hampshire SO17 1BJ	Southampton, Hampshire SO17 1BJ
	United Kingdom	United Kingdom

		EMail: tjc@ecs.soton.ac.uk


	Email: tjc@ecs.soton.ac.uk
	Marshall Eubanks	Marshall Eubanks
	Iformata Communications	Iformata Communications
	130 W. Second Street	130 W. Second Street
	Dayton, Ohio 45402	Dayton, Ohio 45402
	US	US


	Phone: +1 703 501 4376	Phone: +1 703 501 4376

	Email: marshall.eubanks@iformata.com	EMail: marshall.eubanks@iformata.com
	URI: http://www.iformata.com/	URI: http://www.iformata.com/

End of changes. 49 change blocks.
	139 lines changed or deleted	105 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/