Movatterモバイル変換

Network Working Group                                        B. HabermanRequest for Comments: 3306                                    ConsultantCategory: Standards Track                                      D. Thaler                                                               Microsoft                                                             August 2002Unicast-Prefix-based IPv6 Multicast AddressesStatus 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 Contents1. Introduction....................................................22. Motivation......................................................23. Terminology.....................................................24. Multicast Address Format........................................25. Address Lifetime................................................46. Source-Specific Multicast Addresses.............................47. Examples........................................................48. Security Considerations.........................................59. References......................................................5   Author's Address...................................................6   Full Copyright Statement...........................................7Haberman & Thaler           Standards Track                     [Page 1]

RFC 3306          Unicast-Prefix-based IPv6 Multicast        August 20021. 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 20025. 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 20028. 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.comHaberman & Thaler           Standards Track                     [Page 6]

RFC 3306          Unicast-Prefix-based IPv6 Multicast        August 2002Full 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]