[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]