Network Working Group                                          J. Durand
Internet-Draft                                               GIP RENATER
Expires: August 13, 2005                                       P. Savola
                                                               CSC/FUNET
                                                        February 9, 2005


         Route Advertisement Option for IPv6 Multicast Prefixes
                 draft-jdurand-ipv6-multicast-ra-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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.

   This Internet-Draft will expire on August 13, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines a way to advertise IPv6 multicast prefix
   availability using Neighbor Discovery (RFC2461).  This multicast RA
   option can be used by routers to announce a set of multicast prefixes
   that can be on the link to form new group addresses.




Durand & Savola          Expires August 13, 2005                [Page 1]


Internet-Draft     RA Option for IPv6 Multicast Prefix     February 2005


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1  No Solution Needed: SSM  . . . . . . . . . . . . . . . . .   3
     1.2  Out of Scope: Session Announcement/Rendezvous  . . . . . .   4
     1.3  Terminology  . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Other Mechanisms for Address Assignment  . . . . . . . . . .   4
   3.   Multicast Prefix Information Option  . . . . . . . . . . . .   4
   4.   Sending RA with a Multicast Prefix Information Option  . . .   6
   5.   Receiving RA with a Multicast Prefix Information Option  . .   6
     5.1  Processing the Multicast Prefix Information Option . . . .   6
     5.2  Forming an Address from a Multicast Prefix . . . . . . . .   6
   6.   Multicast DAD  . . . . . . . . . . . . . . . . . . . . . . .   7
   7.   Security considerations  . . . . . . . . . . . . . . . . . .   7
   8.   Acknowledgement  . . . . . . . . . . . . . . . . . . . . . .   8
   9.   Open issues / Discussions  . . . . . . . . . . . . . . . . .   8
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1   Normative references . . . . . . . . . . . . . . . . . .   8
     10.2   Informative references . . . . . . . . . . . . . . . . .   8
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .   9
   A.   An Alternative Prefix Information Encoding . . . . . . . . .  10
     A.1  Drawbacks/advantages . . . . . . . . . . . . . . . . . . .  10
        Intellectual Property and Copyright Statements . . . . . . .  12




























Durand & Savola          Expires August 13, 2005                [Page 2]


Internet-Draft     RA Option for IPv6 Multicast Prefix     February 2005


1.  Introduction

   The deployment of IPv6 multicast is rapidly expanding.  Some networks
   have already put the service in production.  Some gateways have been
   deployed, making it possible to have interoperability between IPv4
   and IPv6 multicast.  Some sites have even stopped IPv4 multicast, due
   to its complexity (due to NAT and MSDP for example) and only rely on
   IPv6 multicast, using the deployed gateways for interoperability with
   IPv4.

   As of this writing, most sessions are created manually from
   unicast-prefix based address space [RFC3306], or use SDR to form a
   semi-random address.  Nevertheless these addresses cannot fit with
   embedded-RP [RFC3956] which is the only existing solution for IPv6
   interdomain ASM.

   Some people argue that SSM solves the problem but there is nowadays a
   demand from customers to be capable to have multicast sessions (both
   IPv4 and IPv6) with multiple sources (e.g., conferencing) and it is
   not clear how to achieve this with SSM.  While "multiple-source SSM"
   could potentially be done with the aid of SIP or RTP, this does not
   exist yet, and a simple solution for ASM is needed.

   Section 2.1.2 of [draft-ietf-mboned-addrarch] highlights the fact
   that IPv6 multicast embedded-RP [RFC3956] addresses require an
   assignment mechanism, also justifying work on a multicast address
   assignment mechanism.

   This document defines a multicast prefix information option to be put
   in Neighbor Discovery [RFC2461] Router Advertisement messages.  This
   option can be used by routers to announce a set of multicast prefixes
   that can be used on the link.  A multicast application can then
   choose an address derived from the announced IPv6 multicast prefix to
   start an IPv6 multicast session.

1.1  No Solution Needed: SSM

   The main need today for an assignment mechanism is address uniqueness
   in a defined part of a network.  In the SSM model, as the channel is
   defined by the tuple (source address, group address), a collision can
   only occur if a host is a source in two different multicast sessions,
   using the same source and group addresses.  Therefore, it is
   sufficient for a sender to choose different addresses for different
   channels, and this is a decision local to the host.  Therefore we
   only consider ASM in this document.






Durand & Savola          Expires August 13, 2005                [Page 3]


Internet-Draft     RA Option for IPv6 Multicast Prefix     February 2005


1.2  Out of Scope: Session Announcement/Rendezvous

   This document does not try to describe a solution how the other nodes
   find out which group addresses are generated by the host from the
   prefix.  Session announcement or "rendezvous" can be done e.g., using
   web pages, emails, directories, etc.

1.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 [RFC2119].

2.  Other Mechanisms for Address Assignment

   [draft-ietf-mboned-addrarch] presents the different ways to assign
   today multicast addresses.  It mentions MADCAP [RFC2730] and
   [draft-jdurand-assign-addr-ipv6-multicast-dhcpv6] that are
   client-server protocols for IP multicast address assignment.

   It appears that these solutions can be too complicated in the
   situations where 1) MADCAP service infrastructure is not available
   and cannot be deployed, or 2) DHCPv6 stateful (multicast) address
   assignment is not available and cannot (or there is no desire to) be
   deployed.  Using a Prefix Information option requires no state in the
   network, contrary to DHCPv6 or MADCAP.

   Note that for link-scoped multicast address assignment, hosts must
   use the specifications described in
   [draft-ietf-ipv6-link-scoped-mcast] instead.

3.  Multicast Prefix Information Option

   NOTE: An alternative encoding, re-using the current Prefix
   Information option is presented in Appendix A.

   A router can send multicast prefixes on a link, using the multicast
   prefix information option in router advertisement options.  The
   following figure presents the multicast prefix information option:












Durand & Savola          Expires August 13, 2005                [Page 4]


Internet-Draft     RA Option for IPv6 Multicast Prefix     February 2005


         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      Type     |     Length    | Prefix Length |   Reserved1   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          Valid Lifetime                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                            Multicast                          |
        +                              Prefix                           +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type: (TBD)

   Length: 3

   Prefix Length: 8-bit unsigned integer.  The number of leading bits in
      the Multicast Prefix that are part of the prefix, the rest being
      specific to the link.  The valid values range from 16 to 128.

   Reserved1: 8-bit unused field.  It MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.

   Valid Lifetime: 32-bit unsigned integer.  The length of time in
      seconds (relative to the time the packet is sent) that the prefix
      is valid for the purpose of being used by applications for
      multicast sessions.  A value of all one bits (0xffffffff)
      represents infinity.

   Prefix: An IPv6 address or a prefix of an IPv6 address.  The Prefix
      Length field contains the number of valid leading bits in the
      prefix.  The bits in the prefix after the prefix length are
      reserved and MUST be initialized to zero by the sender and ignored
      by the receiver.  A router SHOULD NOT send a multicast prefix
      option for any prefix that is not a multicast prefix (e.g that is
      not in FF00::/8) and a host SHOULD ignore such a multicast prefix
      option.

   Description: The Multicast Prefix Information option provide hosts
      with a multicast prefix that can be used on the network.  The
      Multicast Prefix Information option appears in Router
      Advertisement packets and MUST be silently ignored for other
      messages.




Durand & Savola          Expires August 13, 2005                [Page 5]


Internet-Draft     RA Option for IPv6 Multicast Prefix     February 2005


4.  Sending RA with a Multicast Prefix Information Option

   Multicast prefix information is sent in RA messages.  Therefore it
   follows the rules described in [RFC2461].  The following rules are
   more specific to multicast prefix information option:

   o  A router includes multicast prefix information option to all the
      RAs (whether solicited or unsolicited) if a multicast prefix has
      been configured.

   o  The multicast prefix information option SHOULD NOT be included if
      there are no multicast prefixes to advertise.


5.  Receiving RA with a Multicast Prefix Information Option

5.1  Processing the Multicast Prefix Information Option

   For each Multicast Prefix Information (MPI) option, a host processes
   it similar to unicast PI (RFC2461, Section 6.3.4):

   o  If the prefix is not a multicast prefix (FF00::/8), silently
      ignore the MPI option.

   o  If the prefix is of the interface- or link-local scope (FFYX::/8,
      for all values of Y where X is "1" or "2"), silently ignore the
      MPI option.

   o  If the prefix is not already present in the Prefix List, and the
      MPI option's Valid Lifetime field is non-zero, create a new entry
      for the prefix and initialize its invalidation timer to the Valid
      Lifetime value in the MPI option.

   o  If the prefix is already present in the host's Prefix List as the
      result of a previously-received advertisement, reset its
      invalidation timer to the Valid Lifetime value in the MPI option.
      If the new Lifetime value is zero, time-out the prefix immediately
      (see Section 6.3.5 of RFC2461).

   o  If the MPI option's Valid Lifetime field is zero, and the prefix
      is not present in the host's Prefix List, silently ignore the
      option.

   This memo does not impose the "two hour rule" of RFC2462.

5.2  Forming an Address from a Multicast Prefix

   If the Prefix Length field is "96" (i.e., the group-id is 32 bits



Durand & Savola          Expires August 13, 2005                [Page 6]


Internet-Draft     RA Option for IPv6 Multicast Prefix     February 2005


   long), a multicast address may be formed automatically.  Otherwise an
   automatic addresss generation MUST NOT be used.

   When an application wants to start a multicast session, it chooses a
   prefix among the the locally stored multicast prefixes.  This prefix
   is chosen following application needs (desired scope etc.) in an
   unspecified manner (e.g., [RFC2771]).  Then the application computes
   an address derived from the prefix chosen.

   This document does not specify the exact algorithm which must be used
   to automatically generate the address.  However, it MUST be generated
   in a random or pseudo-random fashion.  The output of the
   randomization function is 31 random bits which is appended to the
   high-order bit of one to form the group-ID.  ([RFC3307] requires that
   dynamic assignment group-IDs MUST be in the range 0x80000000 to
   0xFFFFFFF.)

6.  Multicast DAD

   A host can perform a DAD when it has chosen a multicast address to
   make sure it is not used on the link at the time being.  However,
   this does not prevent collisions in the cases when nodes creating
   sessions are mobile or have been turned off at the time when DAD is
   performed.

   DAD would only need to be performed to ensure uniqueness within the
   local link, among other hosts which may have auto-generated addresses
   from the dynamic group-ID space.

   It is highly unlikely that 2 hosts on the same link randomly derive
   the same multicast address from the same prefix, and at the moment we
   do not specify an algorithm to check the uniqueness.

7.  Security considerations

   The security considerations related to the Neighbor Discovery
   protocol are discussed in [RFC2461].  The security is similar to that
   of a unicast prefix from the on-link determination perspective
   (RFC2461).

   At the moment, there is no "two hour rule" which is used for unicast
   address autoconfiguration (RFC2462).  This allows anyone on the link
   to invalidate a valid prefix by advertising Valid Lifetime of zero.
   This can be easily fixed if this deemed to be a threat.

   SEND [I-D.ietf-send-ndopt] can be used to sign the messages, but
   additional code would be needed to verify that the prefix in MPI
   option is part of the prefix the router is certified to advertise.



Durand & Savola          Expires August 13, 2005                [Page 7]


Internet-Draft     RA Option for IPv6 Multicast Prefix     February 2005


8.  Acknowledgement

   Stig Venaas provided contributions to the initial draft.

9.  Open issues / Discussions

   Here are the current discussions and questions about this document:

   o  New Prefix Information option, or re-use the existing PI, and
      existing ND mechanisms?

   o  Should the MPI have the "two hour rule" of PI for address
      configuration?

   o  Randomization, do we need to specify the exact algorithm?

   o  Multicast DAD, do we need to define it?  Here or elsewhere?


10.  References

10.1  Normative references

   [I-D.ietf-send-ndopt]
              Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.
              Nikander, "SEcure Neighbor Discovery (SEND)",
              Internet-Draft draft-ietf-send-ndopt-06, July 2004.

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

   [RFC2461]  T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery
              for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [RFC2462]  S. Thomson and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC3307]  B. Haberman, "Allocation Guidelines for IPv6 Multicast
              Addresses", RFC 3307, August 2002.

   [RFC3956]  P. Savola and B. Haberman, "Embedding the Rendezvous Point
              (RP) Address in an IPv6 Multicast Address", November 2004.

10.2  Informative references

   [D343]     6NET project partners, "6NET D3.4.3 - IPv6 multicast
              address allocation study", May 2003.




Durand & Savola          Expires August 13, 2005                [Page 8]


Internet-Draft     RA Option for IPv6 Multicast Prefix     February 2005


   [RFC2730]  S. Hanna, B. Patel and M. Shah, "Multicast Address Dynamic
              Client Allocation Protocol (MADCAP)", RFC 2970, December
              1999.

   [RFC2771]  R. Finlayson, "An Abstract API for Multicast Address
              Allocation", RFC 2771, February 2000.

   [RFC3306]  B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6
              Multicast Addresses", RFC 3306, August 2002.

   [RFC3315]  R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M.
              Carney, "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6)", RFC 3315, July 2003.

   [draft-ietf-ipv6-link-scoped-mcast]
              J-S. Park, M-K. Shin and H-J. Kim, "Link Scoped IPv6
              Multicast Addresses", December 2004.

   [draft-ietf-mboned-addrarch]
              P. Savola, "Overview of the Internet Multicast Addressing
              Architecture", November 2004.

   [draft-jdurand-assign-addr-ipv6-multicast-dhcpv6]
              J. Durand, "IPv6 multicast address assignment with
              DHCPv6", January 2005.


Authors' Addresses

   Jerome Durand
   GIP RENATER
   151 Bd de l'Hopital
   Paris  75013
   France

   Phone: +33 1 53 94 20 30
   Email: Jerome.Durand@renater.fr


   Pekka Savola
   CSC/FUNET
   Espoo
   Finland

   Email: psavola@funet.fi






Durand & Savola          Expires August 13, 2005                [Page 9]


Internet-Draft     RA Option for IPv6 Multicast Prefix     February 2005


Appendix A.  An Alternative Prefix Information Encoding

   Multicast Prefix can be encoded also as follows, based on RFC2461
   section 4.6.2.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     | Prefix Length |L|A| Reserved1 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Valid Lifetime                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Preferred Lifetime                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved2                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                            Prefix                             +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type, Length, Valid Lifetime, Preferred Lifetime, Reserved1 and
   Reserved2 fields are set as specified in RFC2461.

   L (onlink) and A (address configuration) flags MUST be set to zero.
   This prevents the multicast prefix to be used for address
   configuration or onlink determination on non-upgraded hosts which
   don't properly parse a multicast address in the prefix field.

   Prefix Length indicates the number of bits in the prefix which belong
   to the "network" part.  The rest can be used for creating new
   multicast sessions (with caveats of RFC3307).

   Prefix is the multicast prefix.

A.1  Drawbacks/advantages

   Advantages of this approach, compared to a separate option, are:

   o  SEND mechanisms for Prefix Information options work out of the
      box.

   o  Code and specification reuse.  Processing of valid/preferred
      lifetimes etc.  is identical as with unicast prefixes and doesn't



Durand & Savola          Expires August 13, 2005               [Page 10]


Internet-Draft     RA Option for IPv6 Multicast Prefix     February 2005


      need to be discussed here.

   On the other hand, drawbacks are:

   o  Many implementations quietly discard multicast prefixes in the PI
      option.  Some even print a warning message about that.  It will be
      more difficult to know whether the host supports multicast
      prefixes or not.

   o  Code and specification can be reused between two very similar
      options in any case.

   o  Overloading new semantics on old options results in some amount of
      confusion.

   o  SEND doesn't really work (practically, operationally) in any case,
      because someone has to delegate the unicast-prefix based multicast
      addresses in certificates, and I doubt anyone is going to do that
      any time soon..
































Durand & Savola          Expires August 13, 2005               [Page 11]


Internet-Draft     RA Option for IPv6 Multicast Prefix     February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Durand & Savola          Expires August 13, 2005               [Page 12]