summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3306.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3306.txt')
-rw-r--r--doc/rfc/rfc3306.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc3306.txt b/doc/rfc/rfc3306.txt
new file mode 100644
index 0000000..363af6b
--- /dev/null
+++ b/doc/rfc/rfc3306.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group B. Haberman
+Request for Comments: 3306 Consultant
+Category: Standards Track D. Thaler
+ Microsoft
+ August 2002
+
+
+ Unicast-Prefix-based IPv6 Multicast Addresses
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This specification defines an extension to the multicast addressing
+ architecture of the IP Version 6 protocol. The extension presented
+ in this document allows for unicast-prefix-based allocation of
+ 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
+
+ 1. Introduction....................................................2
+ 2. Motivation......................................................2
+ 3. Terminology.....................................................2
+ 4. Multicast Address Format........................................2
+ 5. Address Lifetime................................................4
+ 6. Source-Specific Multicast Addresses.............................4
+ 7. Examples........................................................4
+ 8. Security Considerations.........................................5
+ 9. References......................................................5
+ Author's Address...................................................6
+ Full Copyright Statement...........................................7
+
+
+
+
+
+
+
+Haberman & Thaler Standards Track [Page 1]
+
+RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002
+
+
+1. Introduction
+
+ This document specifies an extension to the multicast portion of the
+ IPv6 addressing architecture [ADDRARCH]. The current architecture
+ does not contain any built-in support for dynamic address allocation.
+ This proposal introduces encoded information in the multicast address
+ to allow for dynamic allocation of IPv6 multicast addresses and IPv6
+ source-specific multicast addresses.
+
+2. Motivation
+
+ The current IPv4 multicast address allocation architecture [RFC 2908]
+ is based on a multi-layered, multi-protocol system. The goal of this
+ proposal is to reduce the number of protocols that need to be
+ deployed in order to get dynamic multicast address allocation.
+
+ The use of unicast prefix-based multicast address allocation will, at
+ a minimum, remove the need to run the Multicast Address Allocation
+ Protocol (AAP) [AAP WORK] and the Multicast Address-Set Claim (MASC)
+ Protocol [RFC 2909].
+
+3. 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].
+
+4. Multicast Address Format
+
+ Section 2.7 of [ADDRARCH] defines the following operational format of
+ IPv6 multicast addresses:
+
+ | 8 | 4 | 4 | 112 |
+ +--------+----+----+---------------------------------------------+
+ |11111111|flgs|scop| group ID |
+ +--------+----+----+---------------------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haberman & Thaler Standards Track [Page 2]
+
+RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002
+
+
+ This document introduces a new format that incorporates unicast
+ prefix information in the multicast address. The following
+ illustrates the new format:
+
+ | 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+ +--------+----+----+--------+--------+----------------+----------+
+ |11111111|flgs|scop|reserved| plen | network prefix | group ID |
+ +--------+----+----+--------+--------+----------------+----------+
+
+ +-+-+-+-+
+ flgs is a set of 4 flags: |0|0|P|T|
+ +-+-+-+-+
+
+ o P = 0 indicates a multicast address that is not assigned
+ based on the network prefix. This indicates a multicast
+ address as defined in [ADDRARCH].
+
+ o P = 1 indicates a multicast address that is assigned based
+ on the network prefix.
+
+ o If P = 1, T MUST be set to 1, otherwise the setting of the T
+ bit is defined in Section 2.7 of [ADDRARCH].
+
+ The reserved field MUST be zero.
+
+ plen indicates the actual number of bits in the network prefix field
+ that identify the subnet when P = 1.
+
+ network prefix identifies the network prefix of the unicast subnet
+ owning the multicast address. If P = 1, this field contains the
+ unicast network prefix assigned to the domain owning, or allocating,
+ the multicast address. All non-significant bits of the network
+ prefix field SHOULD be zero.
+
+ It should be noted that the Interface Identifier requirements in
+ Section 2.5.1 of [ADDRARCH] effectively restrict the length of the
+ unicast prefix to 64 bits, hence the network prefix portion of the
+ multicast address will be at most 64 bits.
+
+ Group ID is set based on the guidelines outlined in [IPV6 GID].
+
+ The scope of the unicast-prefix based multicast address MUST NOT
+ exceed the scope of the unicast prefix embedded in the multicast
+ address.
+
+
+
+
+
+
+
+Haberman & Thaler Standards Track [Page 3]
+
+RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002
+
+
+5. Address Lifetime
+
+ The lifetime of a unicast prefix-based multicast address SHOULD NOT
+ exceed 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]. The
+ lifetime of the multicast address is needed to support the Abstract
+ API for Multicast Address Allocation [RFC 2771].
+
+ It should be noted that the unicast prefix's Valid Lifetime in the
+ Router Advertisement message does not indicate that the prefix will
+ become invalid at the end of the lifetime. Rather, that value is
+ typically a constant until a renumbering event is scheduled after
+ which, the prefix does become invalid.
+
+ The use of unicast prefix-based multicast addresses after the unicast
+ prefix has become invalid may lead to operational problems. For
+ example, routers that perform policy checks comparing the multicast
+ prefix against the unicast prefix assigned to an AS may discard the
+ packet.
+
+6. Source-Specific Multicast Addresses
+
+ The unicast prefix-based IPv6 multicast address format supports
+ Source-specific multicast addresses, as defined by [SSM ARCH]. To
+ accomplish this, a node MUST:
+
+ o Set P = 1.
+ o Set plen = 0.
+ o Set network prefix = 0.
+
+ These settings create an SSM range of FF3x::/32 (where 'x' is any
+ valid scope value). The source address field in the IPv6 header
+ identifies the owner of the multicast address.
+
+7. Examples
+
+ The following are a few examples of the structure of unicast prefix-
+ based multicast addresses.
+
+ - Global prefixes - A network with a unicast prefix of
+ 3FFE:FFFF:1::/48 would also have a unicast prefix-based
+ multicast prefix of FF3x:0030:3FFE:FFFF:0001::/96 (where 'x'
+ is any valid scope).
+
+ - SSM - All IPv6 SSM multicast addresses will have the format
+ FF3x::/96.
+
+
+
+
+Haberman & Thaler Standards Track [Page 4]
+
+RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002
+
+
+8. Security Considerations
+
+ It is possible that the embedded unicast prefix can aid in
+ identifying the allocation domain of a given multicast address,
+ though an allocation domain choosing to avoid being traced has no
+ obstacles currently to creating addresses using a prefix not assigned
+ to it, or using a smaller scope embedded prefix.
+
+ Using source-specific multicast addresses can sometimes aid in the
+ prevention of denial-of-service attacks by arbitrary sources,
+ although no guarantee is provided. A more in-depth discussion of the
+ security considerations for SSM can be found in [SSM ARCH].
+
+9. References
+
+ [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+
+ [RFC 2908] Thaler, D., Handley, M. and D. Estrin, "The Internet
+ Multicast Address Allocation Architecture", RFC 2908,
+ September 2000.
+
+ [AAP WORK] Handley, M. and S. Hanna, "Multicast Address Allocation
+ Protocol (AAP)", Work In Progress.
+
+ [RFC 2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,
+ Kumar, S. and D. Thaler, "The Multicast Address-Set Claim
+ (MASC) Protocol", RFC 2909, September 2000.
+
+ [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1999.
+
+ [IPV6 GID] Haberman, B., "Dynamic Allocation Guidelines for IPv6
+ Multicast Addresses", RFC 3307, June 2002.
+
+ [RFC 2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
+ Discovery for IP Version 6 (IPv6)", RFC 2461, December
+ 1998.
+
+ [RFC 2771] Finlayson, R., "An Abstract API for Multicast Address
+ Allocation", RFC 2771, February 2000.
+
+
+
+
+Haberman & Thaler Standards Track [Page 5]
+
+RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002
+
+
+ [SSM ARCH] Holbrook, H. and B. Cain, "Source-Specific Multicast for
+ IP", Work In Progress.
+
+Author's Address
+
+ Brian Haberman
+ Consultant
+ Phone: 1-919-949-4828
+ EMail: bkhabs@nc.rr.com
+
+ Dave Thaler
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 48105-6399
+ Phone: 1-425-703-8835
+ EMail: dthaler@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haberman & Thaler Standards Track [Page 6]
+
+RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haberman & Thaler Standards Track [Page 7]
+