[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 3306

   IPNGWG Working Group                                        B. Haberman
   Internet Draft                                          Nortel Networks
   draft-ietf-ipngwg-uni-based-mcast-02.txt                      D. Thaler
   June 2001                                                     Microsoft
   Expires December 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
   http://www.ietf.org/ietf/1id-abstracts.txt.

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


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

   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


Internet Draft   Unicast Prefix-based IPv6 Multicast      August 2000


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, unicast prefix-based
   allocation of IPv6 multicast addresses, as well as allocation of
   source-specific multicast addresses.


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
   of IPv6 multicast addresses:

     |    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    |    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.
           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 RFC 2373.

   The reserved field MUST be zero.

Haberman, Thaler                                                     2


Internet Draft   Unicast Prefix-based IPv6 Multicast      August 2000


   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 defined in [RFC 2374] and assigned to the
   domain owning, or allocating, the multicast address.

   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.

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

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


4. Source-Specific Multicast Addresses

   The unicast prefix-based IPv6 multicast address format supports
   Source-specific multicast addresses, as defined by [SSM ARCH].  To
   accomplish is, a node MUST:

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


6. References


Haberman, Thaler                                                     3


Internet Draft   Unicast Prefix-based IPv6 Multicast      August 2000

   [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 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461, December
              1998.

   [SSM ARCH] H. Holbrook and B. Cain, "Source-Specific Multicast
              for IP", Work In Progress, March 2001.































Haberman, Thaler                                                     4




AuthorÆs Address

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

   Dave Thaler
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  48105-6399
   1-425-703-8835
   dthaler@microsoft.com




































Haberman, Thaler                                                     5


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/