idnits 2.17.00 (12 Aug 2021) /tmp/idnits33004/draft-jdurand-all-drs-are-rps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 284. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 300), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2005) is 6328 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 175, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 181, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 184, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 193, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 196, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 199, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 205, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 208, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 212, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 215, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 224, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 236, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 243, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. '2') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '4') (Obsoleted by RFC 4862) ** Downref: Normative reference to an Informational RFC: RFC 2771 (ref. '7') ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '8') ** Obsolete normative reference: RFC 3315 (ref. '12') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3513 (ref. '13') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3633 (ref. '14') (Obsoleted by RFC 8415) -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 16 errors (**), 0 flaws (~~), 16 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Durand 3 Internet-Draft GIP RENATER 4 Expires: July 2, 2005 D. Thaler 5 Microsoft corp. 6 January 2005 8 All DRs all RPs model 9 draft-jdurand-all-drs-are-rps-00 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 2, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). All Rights Reserved. 39 Abstract 41 This document defines a new model for IPv6 ASM (Any Source Multicast) 42 where the Designated Router (DR) on each LAN can serve as a 43 Rendezvous Point (RP) for group addresses formed from the RP address. 44 This keeps group-to-RP mapping simple, while providing for multicast 45 address allocation coordination to be kept within a subnet. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. RP on DR . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.2 Multiple routers on the link . . . . . . . . . . . . . . . 3 53 2.2.1 Anycast RP using PIM . . . . . . . . . . . . . . . . . 4 54 2.2.2 Using a different anycast address . . . . . . . . . . 4 55 3. Security considerations . . . . . . . . . . . . . . . . . . . 4 56 4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Open issues / Discussions . . . . . . . . . . . . . . . . . . 5 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6.1 Normative references . . . . . . . . . . . . . . . . . . . . 5 60 6.2 Informative references . . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 62 Intellectual Property and Copyright Statements . . . . . . . . 8 64 1. Introduction 66 Embedded-RP [15] provides a solution for IPv6 interdomain ASM. 67 Nevertheless, the problem remains of announcing the RP to group 68 creators so that they can build multicast addresses derived from the 69 RP. This issue is raised in section 2.1.2 "Unicast-prefix -based 70 Allocation" of ID.draft-ietf-mboned-addrarch [17]. MADCAP [6] and 71 two other proposals are trying to solve this issue, one based on 72 DHCPv6 [18], and one based on NDP [19]. 74 This memo proposes to change the model used today to solve that 75 issue, avoiding therefore the need of any address assignment 76 mechanism. 78 2. RP on DR 80 Making the assumption that the group creator's DR is the RP, it is 81 possible for any group creator to use embedded-RP [15], by deriving 82 the multicast address from the subnet-router anycast address 83 described in section 2.6.1 of RFC2373 [2]. This means that by knowing 84 its subnet prefix, a group creator can automatically compute the 85 multicast prefix to derive multicast addresses from. This is similar 86 to the use of Unicast-prefix-based multicast addresses [10], but is 87 here applied to Embedded-RP addresses. 89 2.1 Example 91 If we take the example of a group creator on a link where the prefix 92 3FFE:FFFF:1:5::/64 is advertised. When this host wants to start a 93 multicast session, it will use its DR as the RP. Then it uses as RP 94 address the subnet-router anycast address, e.g 3FFE:FFFF:1:5:: 96 From this it computes the multicast prefix derived from this address 97 by using the method described in RFC3956 [15]. The multicast prefix 98 obtained is FF7X:40:3FFE:FFFF:1:5::/96 100 Afterwards the host chooses a group-ID to build the IPv6 multicast 101 address. This group-ID can be assigned through some protocol (e.g., 102 MADCAP [6]), chosen manually, or picked randomly. Unless the 103 group-ID is assigned through some protocol or manual method which 104 ensures uniqueness, some kind of duplicate address detection 105 mechanism (e.g., ZMAAP [21]) could be required afterward to verify 106 that the address is unique within the subnet. This is not specified 107 in this document. 109 2.2 Multiple routers on the link 111 To use the subnet-router anycast address can be a problem in case 112 there are more than one router on the link. While the subnet router 113 anycast address as RP address works for on-link sources, it's not 114 sufficient for remote sources. This is because they will unicast 115 Register messages to the anycast address, which will be delivered to 116 the closest subnet router to the sender, which may not be the RP. 117 Similarly the hop-by-hop Join/Prune messages would stop at the first 118 subnet router rather than going to the RP. Nevertheless, the solution 119 works fine for the general case when there is only one router on the 120 link. Also the 2 following subsections are proposing solutions to 121 this issue. 123 2.2.1 Anycast RP using PIM 125 draft-ietf-pim-anycast-rp-02 [22]would make it possible to manage the 126 aforementioned problem as register messages would be received by all 127 routers of the link. On each router, the list of all other routers of 128 the link would need to be specified. 130 2.2.2 Using a different anycast address 132 Another solution could be to use another anycast address (DR anycast 133 address). RFC 2526 [5] reserves the 128 highest interface IDs of each 134 subnet for this purpose. It could be easy to be allocated one anycast 135 address for DRs on link. Nevertheless, this would not work with 136 embedded-RP as only the 16 addresses with lowest interface IDs on a 137 link can be used. 139 3. Security considerations 141 The use of Embedded-RP addresses does not prevent external users from 142 creating groups in a local RP's group address range. This issue is 143 not specific to this memo; it is a more general problem raised by 144 Embedded-RP [15]. 146 However, if an admin chooses to make an RP only accept data from 147 local sources, this policy is easy to enforce by simply dropping all 148 Register messages coming from outside. 150 If an assignment mechanism is used to build group-IDs, it is then 151 possible only these group-IDs are accepted by the RP. This can be 152 configured in advance for a given range, or some mechanism could be 153 used to inform the RP when new groups are being assigned. Note all 154 the issues raised in this section are more generally linked to 155 Embedded-RP [15]. 157 4. Acknowledgement 159 TBD 161 5. Open issues / Discussions 163 Here are the current discussions and questions about this document: 165 o Shall we specify the randomization method to choose the group-ID? 167 o Multiple routers on the link issue 169 o DAD mechanism 171 6. References 173 6.1 Normative references 175 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 176 Levels", RFC 2119, March 1997. 178 [2] R. Hinden and S. Deering, "IP Version 6 Addressing 179 Architecture", RFC 2373, July 1998. 181 [3] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for 182 IP Version 6 (IPv6)", RFC 2461, December 1998. 184 [4] S. Thomson and T. Narten, "IPv6 Stateless Address 185 Autoconfiguration", RFC 2462, December 1998. 187 [5] D. Johnson and S. Deering, "Reserved IPv6 Subnet Anycast 188 Addresses", RFC 2526, March 1999. 190 [6] S. Hanna, B. Patel and M. Shah, "Multicast Address Dynamic 191 Client Allocation Protocol (MADCAP)", RFC 2730, December 1999. 193 [7] R. Finlayson, "An Abstract API for Multicast Address 194 Allocation", RFC 2771, February 2000. 196 [8] M. Handley, C. Perkins and E. Whelan, "Session Announcement 197 Protocol (SAP)", RFC 2974, October 2000. 199 [9] D. Meyer and P. Lothberg, "GLOP Addressing in 233/8", RFC 3180, 200 September 2001. 202 [10] B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6 Multicast 203 Addresses", RFC 3306, August 2002. 205 [11] B. Haberman, "Allocation Guidelines for IPv6 Multicast 206 Addresses", RFC 3307, August 2002. 208 [12] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. 209 Carney, "Dynamic Host Configuration Protocol for IPv6 210 (DHCPv6)", RFC 3315, July 2003. 212 [13] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6) 213 Addressing Architecture", RFC 3513, April 2003. 215 [14] O. Troan, R. Droms, "IPv6 Prefix Options for Dynamic Host 216 Configuration Protocol (DHCP) version 6", RFC 3633, December 217 2003. 219 [15] P. Savola and B. Haberman, "Embedding the Rendezvous Point (RP) 220 Address in an IPv6 Multicast Address", November 2004. 222 6.2 Informative references 224 [16] 6NET project partners, "6NET D3.4.3 - IPv6 multicast address 225 allocation study", May 2003. 227 [17] P. Savola, "Overview of the Internet Multicast Addressing 228 Architecture", November 2004. 230 [18] J. Durand, "IPv6 multicast address assignment with DHCPv6", 231 January 2005. 233 [19] J. Durand, P. Savola and S. Venaas, "RA for IPv6 multicast 234 prefixes", January 2005. 236 [20] J-S. Park, M-K. Shin and H-J. Kim, "Link Scoped IPv6 Multicast 237 Addresses", December 2004. 239 [21] Octavian Catrina, Dave Thaler, Bernard Aboba and Erik Guttman, 240 "Zeroconf Multicast Address Allocation Protocol (ZMAAP)", 241 October 2002. 243 [22] Dino Farinacci and Yiqun Cai, "Anycast-RP using PIM", June 244 2004. 246 Authors' Addresses 248 Jerome Durand 249 GIP RENATER 250 151 Bd de l'Hopital 251 Paris 75013 252 France 254 Phone: +33 1 53 94 20 30 255 EMail: Jerome.Durand@renater.fr 257 Dave Thaler 258 Microsoft corp. 260 EMail: dthaler@windows.microsoft.com 262 Intellectual Property Statement 264 The IETF takes no position regarding the validity or scope of any 265 Intellectual Property Rights or other rights that might be claimed to 266 pertain to the implementation or use of the technology described in 267 this document or the extent to which any license under such rights 268 might or might not be available; nor does it represent that it has 269 made any independent effort to identify any such rights. Information 270 on the IETF's procedures with respect to rights in IETF Documents can 271 be found in BCP 78 and BCP 79. 273 Copies of IPR disclosures made to the IETF Secretariat and any 274 assurances of licenses to be made available, or the result of an 275 attempt made to obtain a general license or permission for the use of 276 such proprietary rights by implementers or users of this 277 specification can be obtained from the IETF on-line IPR repository at 278 http://www.ietf.org/ipr. 280 The IETF invites any interested party to bring to its attention any 281 copyrights, patents or patent applications, or other proprietary 282 rights that may cover technology that may be required to implement 283 this standard. Please address the information to the IETF at 284 ietf-ipr@ietf.org. 286 Disclaimer of Validity 288 This document and the information contained herein are provided on an 289 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 290 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 291 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 292 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 293 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 294 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 296 Copyright Statement 298 Copyright (C) The Internet Society (2005). This document is subject 299 to the rights, licenses and restrictions contained in BCP 78, and 300 except as set forth therein, the authors retain all their rights. 302 Acknowledgment 304 Funding for the RFC Editor function is currently provided by the 305 Internet Society.