INTERNET DRAFT C. Hsu, E.Muramoto, J. Buford Panasonic Y. Imai Fujitsu Ali Boudani IRISA-France R. Boivie IBM April, 2005 Expires October, 2005 IANA Considerations for XCAST (Explicit Multi-Unicast) Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract XCAST (Explicit Multi-Unicast) is an experimental protocol for small Hsu, et al. Expires October 2005 [Page 1] Internet Draft draft-hsu-xcast-iana-considerations-00.txt April 2005 group multicasting. This protocol requires IANA allocations for a new type of multicast address, a routing type of IPv6 routing header, an option type of Destination Option header and an option header of IPv6 Hop-by-Hop Options header. This document contains guidelines to IANA about what allocations are required for XCAST protocol. Table of Contents 1. Introduction 2. Request for IANA Resources 2.1 Multicast Address for ALL_XCAST_NODES 2.2 Routing Type of IPv6 Routing Header 2.3 Option Type of IPv6 Destination Option Header 2.4 Option Type of IPv6 Hop-by-Hop Options Header 3. Security Considerations 4. References 5. Authors Addresses 6. Full Copyright Statement 7. IPR Notices 1.0 Introduction XCAST (Explicit Multi-Unicast) is an experimental multicasting protocol for efficient small group communications. The XCAST protocol [basic] and related protocols have been proposed as Internet-Drafts (ID) over the past few years. These IDs describe our experiences in building various small group communication protocols and what we have found to be the most important criteria of small group communication protocol design. XCAST experimentation is quite active, and multiple implementations have been developed by several researchers, hackers and companies around the world [bcp]. These results have demonstrated the effectiveness of the XCAST6 design, the interoperability among different platforms and the practical use of XCAST protocols. Given the growing interest in XCAST and the need to conduct more experimentation and testing among a large group of users, developers and industry participants, we would like to accelerate the deployment of XCAST-aware routers. According to RFC 3692 [rfc3692], we believe that experimental values could be obtained through IESG approval. The IANA assignments requested in this document represent the minimum set we believe is needed by the XCAST research community at this time. This document requires IANA allocations for new types and values of IPv6 headers which are defined in the XCAST protocol. Hsu, et al. Expires October 2005 [Page 2] Internet Draft draft-hsu-xcast-iana-considerations-00.txt April 2005 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]. Allocation policy names Specification Required, IETF Consensus Action, and Designated Expert are to be interpreted as described in RFC 2434 [rfc2434] 2. Request for IANA Resources The XCAST protocol requires IANA allocations for a new type of multicast address, a routing type of IPv6 routing header, an option type of Destination Option header and an option header of IPv6 Hope- by-Hop Options header. 2.1 Multicast Address for ALL_XCAST_NODES As defined in section 9.3.1 of [basic], IANA shall assign a new type of multicast address, e.g,: ALL_XCAST_NODES (ff05::10), for identifying the destination address of IPv6 header utilized by the XCAST protocol. 2.2 Routing Type of IPv6 Routing Header As defined in section 9.3.2.1 of [basic], IANA shall assign a new routing type, e.g., RouteType=XCAST, for identifying the message of IPv6 routing header utilized by the XCAST protocol. 2.3 Option Type of IPv6 Destination Option Header As defined in section 9.3.2.2 of [basic], IANA shall assign a new option type, e.g., Option Type=Ports, for identifying the message of IPv6 Destination Options Header utilized by the XCAST protocol. Note that, the first three bits must be "010" to indicate that the packet must be discarded if the option is unknown and that the option can be changed en-route. 2.4 Option Type of IPv6 Hop-by-Hop Options Header As defined in section 11.3 of [basic], IANA shall assign a new option type, e.g., Option Type=XCAST, for identifying the message of IPv6 Hop-by-Hop Options Header utilized by the semi-permeable tunneling mechanism of the XCAST protocol. Note that, the first two bits must be "00" to ensure that routers that cannot recognize XCAST can treat the XCAST datagram as a normal IPv6 datagram and forward it toward the destination in the IPv6 header. Hsu, et al. Expires October 2005 [Page 3] Internet Draft draft-hsu-xcast-iana-considerations-00.txt April 2005 3. Security Considerations This document has no known security implications. 4. References [rfc2026] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [rfc2434] Narten, T., and Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October, 1998. [basic] R. Boivie, et al., "Explicit Multicast (XCAST) Basic Speci- fication",draft-ooms-xcast-basic-spec-07.txt. January 2005 [bcp] Y. Imai, et al., "Best Current Practices of XCAST (Explicit Multi-Unicast) by 2004", draft-imai-xcast-bcp-2004-00.txt. Feburuary 2005. Submitted for Informational RFC. [rfc3692] Narten, T., "Assigning Experimental and Testing Numbers Con- sidered Useful", RFC 3692, January, 2004. 5. Authors Addresses Chih-Chang Hsu Matsushita Electric Industrial Co., Ltd. 4-5-15 Higashi-shinagawa, Shinagawa-ku, Tokyo 140-8632, Japan Phone : +81-3-5460-2734 E-mail: hsu.mike@jp.panasonic.com Eiichi Muramoto Matsushita Electric Industrial Co., Ltd. 4-5-15 Higashi-shinagawa, Shinagawa-ku, Tokyo 140-8632, Japan Phone : +81-3-5460-2734 E-mail: muramoto.eiichi@jp.panasonic.com Yuji Imai Fujitsu LABORATORIES Ltd. 1-1, Kamikodanaka 4-Chome, Nakahara-ku, Kawasaki 211-8588, Japan Phone : +81-44-754-2628 Fax : +81-44-754-2793 E-mail: kimai@flab.fujitsu.co.jp Hsu, et al. Expires October 2005 [Page 4] Internet Draft draft-hsu-xcast-iana-considerations-00.txt April 2005 John F. Buford Panasonic Digital Networking Laboratory Two Research Way, Princeton, NJ 08540, USA Phone : +1-609-734-7342 Fax : +1-609-987-8827 E-mail: buford@research.panasonic.com Ali Boudani IRISA/INRIA Rennes Campus Universitaire de Beaulieu Avenue du General Leclerc 35042 Rennes France Phone : (33) 02 99 84 25 37 Fax : (33) 02 99 84 25 29 E-mail : aboudani@irisa.fr Rick Boivie IBM T. J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 Phone: 914-784-3251 Email: rhboivie@us.ibm.com 7. Full 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. 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. 8. IPR Notices 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. Hsu, et al. Expires October 2005 [Page 5] Internet Draft draft-hsu-xcast-iana-considerations-00.txt April 2005 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. Hsu, et al. Expires October 2005 [Page 6]