idnits 2.17.1 draft-fenner-igmp-proxy-03.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 (2024-04-19) 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) 2024 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 (December 2000) is 8526 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 42 looks like a reference -- Missing reference section? 'Bradner97' on line 53 looks like a reference -- Missing reference section? 'Fenner97' on line 82 looks like a reference -- Missing reference section? 'CDT00' on line 91 looks like a reference -- Missing reference section? 'CDT99' on line 140 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 July 11, 2000 3 draft-fenner-igmp-proxy-03.txt Expires December 2000 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 docu- 11 ments of the Internet Engineering Task Force (IETF), its Areas, and its 12 Working Groups. Note that other groups may also distribute working doc- 13 uments 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 docu- 17 ments at any time. It is not appropriate to use Internet Drafts as ref- 18 erence material or to cite them other than as a "working draft" or "work 19 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 rout- 32 ing protocol. It is sufficient to learn group membership informa- 33 tion and simply forward based upon that information. This draft 34 describes a mechanism for forwarding based solely upon IGMP member- 35 ship information. 37 This document is a product of an individual. Comments are solicited and 38 should be addressed to the author. 40 1. Introduction 42 This document applies spanning tree multicast routing[Deering91] to an 43 IGMP-only environment. The topology is limited to a tree, since we 44 specify no protocol to build a spanning tree over a more complex topol- 45 ogy. The root of the tree is assumed to be connected to a wider multi- 46 cast infrastructure. 48 1.1. Conventions 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [Bradner97]. 54 2. Definitions 56 2.1. Upstream Interface 58 A router's interface in the direction of the root of the tree. 59 Also called the "Host interface". 61 2.2. Downstream Interface 63 Each of a router's interfaces that is not in the direction of the 64 root of the tree. Also called the "Router interfaces". 66 2.3. Membership Database 68 The database maintained at each router into which the membership 69 information of each of its downstream interfaces is merged. 71 2.4. Subscription 73 When using IGMPv2, a group membership on an interface. When using 74 IGMPv3, an IGMPv3 state entry (i.e. a (multicast address, group 75 timer, filter-mode, source-element list) tuple) on an interface. 77 3. Abstract protocol definition 79 A router performing IGMP-based forwarding has a single upstream inter- 80 face and one or more downstream interfaces. These designations are 81 explicitly configured; there is no protocol to determine what type each 82 interface is. It performs the router portion of the IGMP[Fenner97] pro- 83 tocol on its downstream interfaces, and the host portion of IGMP on its 84 upstream interface. The router MUST NOT perform the router portion of 85 IGMP on its upstream interface. 87 The router maintains a database consisting of the merger of all sub- 88 scriptions on any downstream interface. When using IGMPv2, this is a 89 simple union of all group memberships received. When using IGMPv3, the 90 subscriptions are merged using the rules given in the IGMPv3 specifica- 91 tion[CDT00] for merging multiple memberships heard on a single inter- 92 face. 94 The router sends IGMP membership reports on the upstream interface when 95 queried, and sends unsolicited reports or leaves when the database 96 changes. 98 When the router receives a packet destined for a multicast group, it 99 builds a list consisting of the upstream interface and any downstream 100 interface which has a subscription pertaining to this packet and on 101 which it is the IGMP Querier. It removes the interface on which this 102 packet arrived from the list and forwards the packet to the remaining 103 interfaces. 105 Note that the rule that a router must be the querier in order to forward 106 packets restricts the IP addressing scheme used; in particular, the 107 IGMP-based forwarding routers must be given the lowest IP addresses of 108 any potential IGMP Queriers on the link, in order to win the IGMP 109 Querier election. If another device wins the IGMP Querier election, no 110 packets will flow. 112 This rule "piggy-backs" forwarder election on IGMP Querier election; it 113 is necessary for links which multiple IGMP-based forwarders consider to 114 be downstream. On a link with only one IGMP-based forwarding router, 115 this rule MAY be disabled (i.e. the router MAY be configured to forward 116 packets to an interface on which it is not the querier). However, the 117 default configuration MUST include the querier rule. 119 Note that this does not protect against an "upstream loop," where one 120 router's upstream interface is considered to be another's downstream 121 interface and vice versa. A spanning-tree or other tree building algo- 122 rithm is required to resolve loops like this. 124 4. Router Behavior 126 This section describes an IGMP-based multicast forwarding router's 127 actions in more detail. 129 4.1. Membership Database maintenance 131 The router performs the router portion of the IGMP protocol on each 132 downstream interface. The output of this protocol is a set of subscrip- 133 tions; this set is maintained separately on each downstream interface. 134 In addition, the subscriptions on each downstream interface are merged 135 into the membership database. 137 When using IGMPv2, the membership database simply contains the union of 138 all subscriptions on downstream interfaces. When using IGMPv3, the 139 merging rules for multiple memberships on a single interface specified 140 in the IGMPv3 specification[CDT99] are used to merge all subscriptions 141 on downstream interfaces to create the membership database. 143 When the composition of the membership database changes (e.g. the first 144 downstream member joins or the last downstream member leaves, or a down- 145 stream member changes its IGMPv3 source subscriptions), the change in 146 the database is reported on the upstream interface as though this router 147 were a host performing the action. For example, when an IGMPv2 group 148 member first appears on a downstream interface and the router is per- 149 forming IGMPv2 on its upstream interface, the router sends [Robustness 150 Interval] IGMPv2 reports on the upstream interface. 152 4.2. Forwarding Packets 154 A router forwards packets received on its upstream interface to each 155 downstream interface based upon the downstream interface's subscriptions 156 and whether or not this router is the IGMP Querier on each interface. A 157 router forwards packets received on any downstream interface to the 158 upstream interface, and to each downstream interface other than the 159 incoming interface based upon the downstream interfaces' subscriptions 160 and whether or not this router is the IGMP Querier on each interface. A 161 router MAY use a forwarding cache in order not to make this decision for 162 each packet, but MUST update the cache using these rules any time any of 163 the information used to build it changes. 165 5. Security Considerations 167 - Since only the Querier forwards packets, the IGMP Querier election 168 process may lead to black holes if a non-forwarder is elected Querier. 169 An attacker on a downstream LAN can cause itself to get elected 170 Querier resulting in no packets being forwarded. 172 6. References 174 Bradner97 Bradner, S., "Key words for use in RFCs to Indicate 175 Requirement Levels", RFC 2119/BCP 14, Harvard University, 176 March 1997. 178 CDT00 Cain, B., S. Deering and A. Thyagarajan, "Internet Group 179 Management Protocol, Version 3". Work in progress. 181 Deering91 Deering, S., "Multicast Routing in a Datagram Internet- 182 work", Ph.D. Thesis, Stanford University, December 1991. 184 Fenner97 Fenner, W. ``Internet Group Management Protocol, Version 185 2'', RFC 2236, Xerox PARC, November 1997. 187 7. Author's Address 189 William C. Fenner 190 AT&T Labs - Research 191 75 Willow Rd 192 Menlo Park, CA 94025 193 Phone: +1 650 330 7893 194 Email: fenner@research.att.com