IPNGWG Working Group                                         B. Haberman
   Internet Draft                                           Nortel Networks
   draft-ietf-ipngwg-uni-based-mcast-00.txt                       D. Thaler
   August 2000                                                    Microsoft
   Expires February 2001

             Unicast-Prefix-based IPv6 Multicast Addresses

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   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.

1. Introduction

   This document specifies an extension to the multicast portion of the
   IPv6 addressing architecture [RFC 2373].  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, network prefix-based
   allocation of IPv6 multicast addresses, as well as allocation of
   source-specific multicast addresses.

2. Multicast Address Format

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

Haberman, Thaler                                                     1

Internet Draft   Unicast Prefix-based IPv6 Multicast       August 2000

     |    8   |  4 |  4 |               80               |     32     |
     |11111111|flgs|scop|     reserved must be zero      | group ID   |

   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  |      plen      |72 - plen |    32    |
     |11111111|flgs|scop| plen | network prefix | reserved | 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.
           o  P = 1 indicates a multicast address that is assigned
              based on the network prefix.
           o  The setting of the T bit is defined in Section 2.7 of RFC

   plen indicates the length of the network prefix portion of the
   address when P = 1.  This field is required in order to determine
   the number of bits to include as part of the unicast prefix.

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

   The reserved field MUST be zero.

   While this limits the number of unicast prefix-based IPv6 multicast
   groups to 2^32 per prefix, this is unlikely to be a limitation in
   the future.  If it becomes necessary to exceed this limit in the
   future, multicast will still work but the processing will be
   slightly slower.

   With the network prefix-based architecture and the current unicast
   address architecture [RFC 2374], the network prefix portion of the
   multicast address will be at most 64 bits.  This allows for the
   group ID field to be at least 40 bits.

Haberman, Thaler                                                     2

Internet Draft   Unicast Prefix-based IPv6 Multicast       August 2000

3. 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
           o  Setting plen = 0
           o  Setting network prefix = 0

4. Security Considerations

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

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

5. References

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

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

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

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

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

   [RFC 2464] M. Crawford, "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, 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.

Haberman, Thaler                                                     3

Internet Draft   Unicast Prefix-based IPv6 Multicast       August 2000

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

   [IANA]     D. Cheriton, "Single-source IP Multicast Address Range",
              source-multicast, October 1998.

Haberman, Thaler                                                     4

Author's Address

   Brian Haberman
   Nortel Networks
   4309 Emperor Blvd.
   Suite 200
   Durham, NC  27703
   Email : haberman@nortelnetworks.com

   Dave Thaler
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  48105-6399
   Email: dthaler@microsoft.com

Haberman, Thaler                                                     5