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]