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]