Diff: draft-ietf-ipngwg-uni-based-mcast-01.txt - draft-ietf-ipngwg-uni-based-mcast-02.txt

	< draft-ietf-ipngwg-uni-based-mcast-01.txt	draft-ietf-ipngwg-uni-based-mcast-02.txt >

	IPNGWG Working Group B. Haberman	IPNGWG Working Group B. Haberman
	Internet Draft Nortel Networks	Internet Draft Nortel Networks

	draft-ietf-ipngwg-uni-based-mcast-01.txt D. Thaler	draft-ietf-ipngwg-uni-based-mcast-02.txt D. Thaler
	January 2001 Microsoft	June 2001 Microsoft
	Expires July 2001	Expires December 2001

	Unicast-Prefix-based IPv6 Multicast Addresses	Unicast-Prefix-based IPv6 Multicast Addresses

	Status of this Memo	Status of this Memo

	This document is an Internet-Draft and is in full conformance with	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026 [RFC 2026].	all provisions of Section 10 of RFC2026 [RFC 2026].

	Internet-Drafts are working documents of the Internet Engineering	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that	Task Force (IETF), its areas, and its working groups. Note that

	skipping to change at line 34 ¶	skipping to change at line 34 ¶
	http://www.ietf.org/ietf/1id-abstracts.txt.	http://www.ietf.org/ietf/1id-abstracts.txt.

	The list of Internet-Draft Shadow Directories can be accessed at	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.	http://www.ietf.org/shadow.html.

	Abstract	Abstract

	This specification defines an extension to the multicast addressing	This specification defines an extension to the multicast addressing
	architecture of the IP Version 6 protocol. The extension presented	architecture of the IP Version 6 protocol. The extension presented
	in this document allows for unicast-prefix-based allocation of	in this document allows for unicast-prefix-based allocation of

	multicast addresses.	multicast addresses. By delegating multicast addresses at the same
		time as unicast prefixes, network operators will be able to identify
		their multicast addresses without needing to run an inter-domain
		allocation protocol.


		Table of Contents

		Status of this Memo................................................1
		Abstract...........................................................1
		1. Introduction....................................................2
		2. Terminology.....................................................2
		3. Multicast Address Format........................................2
		4. Source-Specific Multicast Addresses.............................3
		5. Security Considerations.........................................3
		6. References......................................................3
		Author�s Address...................................................5

		Haberman, Thaler 1
	1. Introduction	1. Introduction

	This document specifies an extension to the multicast portion of the	This document specifies an extension to the multicast portion of the
	IPv6 addressing architecture [RFC 2373]. The current architecture	IPv6 addressing architecture [RFC 2373]. The current architecture
	does not contain any built-in support for dynamic address	does not contain any built-in support for dynamic address
	allocation. This proposal introduces encoded information in the	allocation. This proposal introduces encoded information in the

	multicast address to allow for dynamic, network prefix-based	multicast address to allow for dynamic, unicast prefix-based
	allocation of IPv6 multicast addresses, as well as allocation of	allocation of IPv6 multicast addresses, as well as allocation of
	source-specific multicast addresses.	source-specific multicast addresses.


	2. Multicast Address Format	2. Terminology

		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
		this document are to be interpreted as described in [RFC 2119].

		3. Multicast Address Format

	Section 2.7.2 of RFC 2373 defines the following operational format	Section 2.7.2 of RFC 2373 defines the following operational format
	of IPv6 multicast addresses:	of IPv6 multicast addresses:


	Haberman, Thaler 1
	\| 8 \| 4 \| 4 \| 80 \| 32 \|	\| 8 \| 4 \| 4 \| 80 \| 32 \|
	+--------+----+----+--------------------------------+------------+	+--------+----+----+--------------------------------+------------+
	\|11111111\|flgs\|scop\| reserved must be zero \| group ID \|	\|11111111\|flgs\|scop\| reserved must be zero \| group ID \|
	+--------+----+----+--------------------------------+------------+	+--------+----+----+--------------------------------+------------+

	This document introduces a new format that incorporates unicast	This document introduces a new format that incorporates unicast
	prefix information in the multicast address. The following	prefix information in the multicast address. The following
	illustrates the new format:	illustrates the new format:

	\| 8 \| 4 \| 4 \| 8 \| 8 \| 64 \| 32 \|	\| 8 \| 4 \| 4 \| 8 \| 8 \| 64 \| 32 \|

	skipping to change at line 74 ¶	skipping to change at line 95 ¶
	+--------+----+----+--------+--------+----------------+----------+	+--------+----+----+--------+--------+----------------+----------+

	+-+-+-+-+	+-+-+-+-+
	flgs is a set of 4 flags: \|0\|0\|P\|T\|	flgs is a set of 4 flags: \|0\|0\|P\|T\|
	+-+-+-+-+	+-+-+-+-+

	o P = 0 indicates a multicast address that is not assigned	o P = 0 indicates a multicast address that is not assigned
	based on the network prefix.	based on the network prefix.
	o P = 1 indicates a multicast address that is assigned	o P = 1 indicates a multicast address that is assigned
	based on the network prefix.	based on the network prefix.

	o The setting of the T bit is defined in Section 2.7 of RFC	o If P = 1, T MUST be set to 1, otherwise the setting of
	2373	the T bit is defined in Section 2.7 of RFC 2373.

	The reserved field MUST be zero.	The reserved field MUST be zero.


	plen indicates the actual length of the network prefix portion of	Haberman, Thaler 2
	the address when P = 1. This field is required in order to	plen indicates the actual number of bits in the network prefix field
	determine the number of bits to include as part of the unicast	that identify the subnet when P = 1.
	prefix.

	network prefix identifies the network prefix of the unicast subnet	network prefix identifies the network prefix of the unicast subnet
	owning the multicast address. If P = 1, this field contains the	owning the multicast address. If P = 1, this field contains the
	unicast network prefix defined in [RFC 2374] and assigned to the	unicast network prefix defined in [RFC 2374] and assigned to the
	domain owning, or allocating, the multicast address.	domain owning, or allocating, the multicast address.

	With the network prefix-based architecture and the current unicast	With the network prefix-based architecture and the current unicast
	address architecture [RFC 2374], the network prefix portion of the	address architecture [RFC 2374], the network prefix portion of the
	multicast address will be at most 64 bits.	multicast address will be at most 64 bits.


	The scope of the unicast-prefix based multicast address must not	The scope of the unicast-prefix based multicast address MUST NOT
	exceed the scope of the unicast prefix embedded in the multicast	exceed the scope of the unicast prefix embedded in the multicast
	address.	address.


	3. Source-Specific Multicast Addresses	The lifetime of a unicast prefix-based multicast addresses MUST be
		less than or equal to the Valid Lifetime field in the Prefix
		Information option, corresponding to the unicast prefix being used,
		contained in the Neighbor Discovery Router Advertisement message
		[RFC 2461].


	Haberman, Thaler 2	4. Source-Specific Multicast Addresses
	The network prefix-based IPv6 multicast address format supports
	Source-specific multicast addresses, as defined by [IANA]. This is
	accomplished by:


	o Setting P = 1	The unicast prefix-based IPv6 multicast address format supports
	o Setting plen = 0	Source-specific multicast addresses, as defined by [SSM ARCH]. To
	o Setting network prefix = 0	accomplish is, a node MUST:


	4. Security Considerations	o Set P = 1.
		o Set plen = 0.
		o Set network prefix = 0.

		These settings indicate that the multicast address is being used in
		source-specific multicast transmission. The source address field in
		the IPv6 header identifies the owner of the multicast address.

		5. Security Considerations

	Using unicast network-prefix based multicast addresses can sometimes	Using unicast network-prefix based multicast addresses can sometimes
	aid in identifying the allocation domain of a given multicast	aid in identifying the allocation domain of a given multicast
	address, although no guarantee is provided.	address, although no guarantee is provided.

	Using source-specific multicast addresses can sometimes aid in the	Using source-specific multicast addresses can sometimes aid in the
	prevention of denial-of-service attacks by arbitrary sources,	prevention of denial-of-service attacks by arbitrary sources,
	although no guarantee is provided.	although no guarantee is provided.


	5. IANA Considerations

	Well-known, fixed-scope and variable-scope multicast addresses with
	the prefix FF2x (unicast-prefix based, permanent) may be created and
	used as follows.

	Group IDs are defined and registered by the IANA. Such well-known
	group IDs may be used to create unicast-prefix based multicast
	addresses by any domain or network by embedding their local unicast
	prefix. Hence, given an IANA-assigned group ID, and a unicast
	network prefix, an application could derive and join that network's
	group used for the well-known purpose associated with the group ID.

	6. References	6. References


		Haberman, Thaler 3

	[RFC 2026] S. Bradner, "The Internet Standards Process --	[RFC 2026] S. Bradner, "The Internet Standards Process --
	Revision 3", BCP 9, RFC 2026, October 1996.	Revision 3", BCP 9, RFC 2026, October 1996.

	[RFC 2460] S. Deering and R. Hinden, "Internet Protocol, Version 6	[RFC 2460] S. Deering and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.	(IPv6) Specification", RFC 2460, December 1998.

	[RFC 2373] R. Hinden and S. Deering, "IP Version 6 Addressing	[RFC 2373] R. Hinden and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 2373, July 1998.	Architecture", RFC 2373, July 1998.

	[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate	[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, BCP14, March 1999.	Requirement Levels", RFC 2119, BCP14, March 1999.

	[RFC 2374] R. Hinden, M. O�Dell, and S. Deering, "An IPv6	[RFC 2374] R. Hinden, M. O�Dell, and S. Deering, "An IPv6
	Aggregatable Global Unicast Address Format", RFC 2374,	Aggregatable Global Unicast Address Format", RFC 2374,


	Haberman, Thaler 3
	July 1998.	July 1998.


	[RFC 2464] M. Crawford, "Transmission of IPv6 Packets over Ethernet	[RFC 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor
	Networks", RFC 2464, December 1998.	Discovery for IP Version 6 (IPv6)", RFC 2461, December
		1998.
	[RFC 2470] M. Crawford, T. Narten, and S. Thomas, "Transmission of
	IPv6 Packets over Token Ring Networks", RFC 2470,
	December 1998.

	[RFC 2375] R. Hinden and S. Deering, "IPv6 Multicast Address
	Assignments", RFC 2375, July 1998.

	[RFC 2365] D. Meyer, "Administratively Scoped IP Multicast",
	BCP 23, RFC 2365, July 1998.


	[IANA] D. Cheriton, "Single-source IP Multicast Address Range",	[SSM ARCH] H. Holbrook and B. Cain, "Source-Specific Multicast
	http://www.isi.edu/in-notes/iana/assignments/single-	for IP", Work In Progress, March 2001.
	source-multicast, October 1998.

	Haberman, Thaler 4	Haberman, Thaler 4
	Author�s Address	Author�s Address

	Brian Haberman	Brian Haberman
	Nortel Networks	Nortel Networks
	4309 Emperor Blvd.	4309 Emperor Blvd.
	Suite 200	Suite 200
	Durham, NC 27703	Durham, NC 27703
	1-919-992-4439	1-919-992-4439

	Email : haberman@nortelnetworks.com	haberman@nortelnetworks.com

	Dave Thaler	Dave Thaler
	Microsoft Corporation	Microsoft Corporation
	One Microsoft Way	One Microsoft Way
	Redmond, WA 48105-6399	Redmond, WA 48105-6399
	1-425-703-8835	1-425-703-8835

	Email: dthaler@microsoft.com	dthaler@microsoft.com

	Haberman, Thaler 5	Haberman, Thaler 5

End of changes. 20 change blocks.
	55 lines changed or deleted	61 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/