Network Working Group J. Durand Internet-Draft GIP RENATER Expires: July 2, 2005 D. Thaler Microsoft corp. January 2005 All DRs all RPs model draft-jdurand-all-drs-are-rps-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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 July 2, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document defines a new model for IPv6 ASM (Any Source Multicast) where the Designated Router (DR) on each LAN can serve as a Rendezvous Point (RP) for group addresses formed from the RP address. This keeps group-to-RP mapping simple, while providing for multicast address allocation coordination to be kept within a subnet. Durand & Thaler Expires July 2, 2005 [Page 1] Internet-Draft All DRs all RPs model January 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. RP on DR . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Multiple routers on the link . . . . . . . . . . . . . . . 3 2.2.1 Anycast RP using PIM . . . . . . . . . . . . . . . . . 4 2.2.2 Using a different anycast address . . . . . . . . . . 4 3. Security considerations . . . . . . . . . . . . . . . . . . . 4 4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4 5. Open issues / Discussions . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1 Normative references . . . . . . . . . . . . . . . . . . . . 5 6.2 Informative references . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 8 Durand & Thaler Expires July 2, 2005 [Page 2] Internet-Draft All DRs all RPs model January 2005 1. Introduction Embedded-RP [15] provides a solution for IPv6 interdomain ASM. Nevertheless, the problem remains of announcing the RP to group creators so that they can build multicast addresses derived from the RP. This issue is raised in section 2.1.2 "Unicast-prefix -based Allocation" of ID.draft-ietf-mboned-addrarch [17]. MADCAP [6] and two other proposals are trying to solve this issue, one based on DHCPv6 [18], and one based on NDP [19]. This memo proposes to change the model used today to solve that issue, avoiding therefore the need of any address assignment mechanism. 2. RP on DR Making the assumption that the group creator's DR is the RP, it is possible for any group creator to use embedded-RP [15], by deriving the multicast address from the subnet-router anycast address described in section 2.6.1 of RFC2373 [2]. This means that by knowing its subnet prefix, a group creator can automatically compute the multicast prefix to derive multicast addresses from. This is similar to the use of Unicast-prefix-based multicast addresses [10], but is here applied to Embedded-RP addresses. 2.1 Example If we take the example of a group creator on a link where the prefix 3FFE:FFFF:1:5::/64 is advertised. When this host wants to start a multicast session, it will use its DR as the RP. Then it uses as RP address the subnet-router anycast address, e.g 3FFE:FFFF:1:5:: From this it computes the multicast prefix derived from this address by using the method described in RFC3956 [15]. The multicast prefix obtained is FF7X:40:3FFE:FFFF:1:5::/96 Afterwards the host chooses a group-ID to build the IPv6 multicast address. This group-ID can be assigned through some protocol (e.g., MADCAP [6]), chosen manually, or picked randomly. Unless the group-ID is assigned through some protocol or manual method which ensures uniqueness, some kind of duplicate address detection mechanism (e.g., ZMAAP [21]) could be required afterward to verify that the address is unique within the subnet. This is not specified in this document. 2.2 Multiple routers on the link To use the subnet-router anycast address can be a problem in case Durand & Thaler Expires July 2, 2005 [Page 3] Internet-Draft All DRs all RPs model January 2005 there are more than one router on the link. While the subnet router anycast address as RP address works for on-link sources, it's not sufficient for remote sources. This is because they will unicast Register messages to the anycast address, which will be delivered to the closest subnet router to the sender, which may not be the RP. Similarly the hop-by-hop Join/Prune messages would stop at the first subnet router rather than going to the RP. Nevertheless, the solution works fine for the general case when there is only one router on the link. Also the 2 following subsections are proposing solutions to this issue. 2.2.1 Anycast RP using PIM draft-ietf-pim-anycast-rp-02 [22]would make it possible to manage the aforementioned problem as register messages would be received by all routers of the link. On each router, the list of all other routers of the link would need to be specified. 2.2.2 Using a different anycast address Another solution could be to use another anycast address (DR anycast address). RFC 2526 [5] reserves the 128 highest interface IDs of each subnet for this purpose. It could be easy to be allocated one anycast address for DRs on link. Nevertheless, this would not work with embedded-RP as only the 16 addresses with lowest interface IDs on a link can be used. 3. Security considerations The use of Embedded-RP addresses does not prevent external users from creating groups in a local RP's group address range. This issue is not specific to this memo; it is a more general problem raised by Embedded-RP [15]. However, if an admin chooses to make an RP only accept data from local sources, this policy is easy to enforce by simply dropping all Register messages coming from outside. If an assignment mechanism is used to build group-IDs, it is then possible only these group-IDs are accepted by the RP. This can be configured in advance for a given range, or some mechanism could be used to inform the RP when new groups are being assigned. Note all the issues raised in this section are more generally linked to Embedded-RP [15]. 4. Acknowledgement TBD Durand & Thaler Expires July 2, 2005 [Page 4] Internet-Draft All DRs all RPs model January 2005 5. Open issues / Discussions Here are the current discussions and questions about this document: o Shall we specify the randomization method to choose the group-ID? o Multiple routers on the link issue o DAD mechanism 6. References 6.1 Normative references [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] R. Hinden and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [3] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [4] S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [5] D. Johnson and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999. [6] S. Hanna, B. Patel and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999. [7] R. Finlayson, "An Abstract API for Multicast Address Allocation", RFC 2771, February 2000. [8] M. Handley, C. Perkins and E. Whelan, "Session Announcement Protocol (SAP)", RFC 2974, October 2000. [9] D. Meyer and P. Lothberg, "GLOP Addressing in 233/8", RFC 3180, September 2001. [10] B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002. [11] B. Haberman, "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002. Durand & Thaler Expires July 2, 2005 [Page 5] Internet-Draft All DRs all RPs model January 2005 [12] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [13] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [14] O. Troan, R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [15] P. Savola and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", November 2004. 6.2 Informative references [16] 6NET project partners, "6NET D3.4.3 - IPv6 multicast address allocation study", May 2003. [17] P. Savola, "Overview of the Internet Multicast Addressing Architecture", November 2004. [18] J. Durand, "IPv6 multicast address assignment with DHCPv6", January 2005. [19] J. Durand, P. Savola and S. Venaas, "RA for IPv6 multicast prefixes", January 2005. [20] J-S. Park, M-K. Shin and H-J. Kim, "Link Scoped IPv6 Multicast Addresses", December 2004. [21] Octavian Catrina, Dave Thaler, Bernard Aboba and Erik Guttman, "Zeroconf Multicast Address Allocation Protocol (ZMAAP)", October 2002. [22] Dino Farinacci and Yiqun Cai, "Anycast-RP using PIM", June 2004. Durand & Thaler Expires July 2, 2005 [Page 6] Internet-Draft All DRs all RPs model 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 Dave Thaler Microsoft corp. EMail: dthaler@windows.microsoft.com Durand & Thaler Expires July 2, 2005 [Page 7] Internet-Draft All DRs all RPs model January 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 IETF's procedures with respect to rights in IETF 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 & Thaler Expires July 2, 2005 [Page 8]