idnits 2.17.00 (12 Aug 2021) /tmp/idnits17346/draft-ietf-idmr-igmp-proxy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-21) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (October 2001) is 7523 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) -- Missing reference section? 'Deering91' on line 44 looks like a reference -- Missing reference section? 'Bradner97' on line 55 looks like a reference -- Missing reference section? 'Fenner97' on line 84 looks like a reference -- Missing reference section? 'CDFKT01' on line 93 looks like a reference -- Missing reference section? 'CDT99' on line 142 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force W. Fenner 2 INTERNET-DRAFT April 3, 2001 3 draft-ietf-idmr-igmp-proxy-00.txt Expires October 2001 5 IGMP-based Multicast Forwarding (``IGMP Proxying'') 7 Status of this Memo 9 This document is an Internet Draft and is in full conformance with all 10 provisions of Section 10 of RFC2026. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, and 12 its Working Groups. Note that other groups may also distribute working 13 documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six months. 16 Internet Drafts may be updated, replaced, or obsoleted by other 17 documents at any time. It is not appropriate to use Internet Drafts as 18 reference material or to cite them other than as a "working draft" or 19 "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt. 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Distribution of this document is unlimited. 29 Abstract 31 In certain topologies, it is not necessary to run a multicast 32 routing protocol. It is sufficient to learn group membership 33 information and simply forward based upon that information. This 34 draft describes a mechanism for forwarding based solely upon IGMP 35 membership information. 37 This document is a product of the IDMR working group within the Internet 38 Engineering Task Force. Comments are solicited and should be addressed 39 to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the 40 author. 42 1. Introduction 44 This document applies spanning tree multicast routing[Deering91] to an 45 IGMP-only environment. The topology is limited to a tree, since we 46 specify no protocol to build a spanning tree over a more complex 47 topology. The root of the tree is assumed to be connected to a wider 48 multicast infrastructure. 50 1.1. Conventions 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [Bradner97]. 56 2. Definitions 58 2.1. Upstream Interface 60 A router's interface in the direction of the root of the tree. 61 Also called the "Host interface". 63 2.2. Downstream Interface 65 Each of a router's interfaces that is not in the direction of the 66 root of the tree. Also called the "Router interfaces". 68 2.3. Membership Database 70 The database maintained at each router into which the membership 71 information of each of its downstream interfaces is merged. 73 2.4. Subscription 75 When using IGMPv2, a group membership on an interface. When using 76 IGMPv3, an IGMPv3 state entry (i.e. a (multicast address, group 77 timer, filter-mode, source-element list) tuple) on an interface. 79 3. Abstract protocol definition 81 A router performing IGMP-based forwarding has a single upstream 82 interface and one or more downstream interfaces. These designations are 83 explicitly configured; there is no protocol to determine what type each 84 interface is. It performs the router portion of the IGMP[Fenner97] 85 protocol on its downstream interfaces, and the host portion of IGMP on 86 its upstream interface. The router MUST NOT perform the router portion 87 of IGMP on its upstream interface. 89 The router maintains a database consisting of the merger of all 90 subscriptions on any downstream interface. When using IGMPv2, this is a 91 simple union of all group memberships received. When using IGMPv3, the 92 subscriptions are merged using the rules given in the IGMPv3 93 specification[CDFKT01] for merging multiple memberships heard on a 94 single interface. 96 The router sends IGMP membership reports on the upstream interface when 97 queried, and sends unsolicited reports or leaves when the database 98 changes. 100 When the router receives a packet destined for a multicast group, it 101 builds a list consisting of the upstream interface and any downstream 102 interface which has a subscription pertaining to this packet and on 103 which it is the IGMP Querier. It removes the interface on which this 104 packet arrived from the list and forwards the packet to the remaining 105 interfaces. 107 Note that the rule that a router must be the querier in order to forward 108 packets restricts the IP addressing scheme used; in particular, the 109 IGMP-based forwarding routers must be given the lowest IP addresses of 110 any potential IGMP Queriers on the link, in order to win the IGMP 111 Querier election. If another device wins the IGMP Querier election, no 112 packets will flow. 114 This rule "piggy-backs" forwarder election on IGMP Querier election; it 115 is necessary for links which multiple IGMP-based forwarders consider to 116 be downstream. On a link with only one IGMP-based forwarding router, 117 this rule MAY be disabled (i.e. the router MAY be configured to forward 118 packets to an interface on which it is not the querier). However, the 119 default configuration MUST include the querier rule. 121 Note that this does not protect against an "upstream loop," where one 122 router's upstream interface is considered to be another's downstream 123 interface and vice versa. A spanning-tree or other tree building 124 algorithm is required to resolve loops like this. 126 4. Router Behavior 128 This section describes an IGMP-based multicast forwarding router's 129 actions in more detail. 131 4.1. Membership Database maintenance 133 The router performs the router portion of the IGMP protocol on each 134 downstream interface. The output of this protocol is a set of 135 subscriptions; this set is maintained separately on each downstream 136 interface. In addition, the subscriptions on each downstream interface 137 are merged into the membership database. 139 When using IGMPv2, the membership database simply contains the union of 140 all subscriptions on downstream interfaces. When using IGMPv3, the 141 merging rules for multiple memberships on a single interface specified 142 in the IGMPv3 specification[CDT99] are used to merge all subscriptions 143 on downstream interfaces to create the membership database. 145 When the composition of the membership database changes (e.g. the first 146 downstream member joins or the last downstream member leaves, or a 147 downstream member changes its IGMPv3 source subscriptions), the change 148 in the database is reported on the upstream interface as though this 149 router were a host performing the action. For example, when an IGMPv2 150 group member first appears on a downstream interface and the router is 151 performing IGMPv2 on its upstream interface, the router sends 152 [Robustness Variable] IGMPv2 reports on the upstream interface. 154 4.2. Forwarding Packets 156 A router forwards packets received on its upstream interface to each 157 downstream interface based upon the downstream interface's subscriptions 158 and whether or not this router is the IGMP Querier on each interface. A 159 router forwards packets received on any downstream interface to the 160 upstream interface, and to each downstream interface other than the 161 incoming interface based upon the downstream interfaces' subscriptions 162 and whether or not this router is the IGMP Querier on each interface. A 163 router MAY use a forwarding cache in order not to make this decision for 164 each packet, but MUST update the cache using these rules any time any of 165 the information used to build it changes. 167 5. Security Considerations 169 - Since only the Querier forwards packets, the IGMP Querier election 170 process may lead to black holes if a non-forwarder is elected Querier. 171 An attacker on a downstream LAN can cause itself to get elected 172 Querier resulting in no packets being forwarded. 174 6. References 176 Bradner97 Bradner, S., "Key words for use in RFCs to Indicate 177 Requirement Levels", RFC 2119/BCP 14, Harvard University, 178 March 1997. 180 CDFKT01 Cain, B., S. Deering, B. Fenner, I. Kouvelas and A. 181 Thyagarajan, "Internet Group Management Protocol, Version 182 3". Work in progress. (draft-ietf-idmr-igmp-v3-07.txt) 184 Deering91 Deering, S., "Multicast Routing in a Datagram 185 Internetwork", Ph.D. Thesis, Stanford University, 186 December 1991. 188 Fenner97 Fenner, W. ``Internet Group Management Protocol, Version 189 2'', RFC 2236, Xerox PARC, November 1997. 191 7. Author's Address 193 William C. Fenner 194 AT&T Labs - Research 195 75 Willow Rd 196 Menlo Park, CA 94025 197 Phone: +1 650 330 7893 198 Email: fenner@research.att.com