idnits 2.17.1 draft-ietf-magma-igmp-proxy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: An interface can be configured to perform IGMPv1 or IGMPv2. In this scenario, the SSM semantic will not be maintained for that interface. However, a router that supports this document should ignore those IGMPv1 or IGMPv2 subscriptions sent to SSM addresses. And more importantly, the packets with source-specific addresses SHOULD not be forwarded to interfaces with IGMPv2 or IGMPv1 subscriptions for these addresses. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 45 looks like a reference -- Missing reference section? 'Bradner97' on line 56 looks like a reference -- Missing reference section? 'Deering89' on line 95 looks like a reference -- Missing reference section? 'Fenner97' on line 95 looks like a reference -- Missing reference section? 'CDFKT01' on line 198 looks like a reference -- Missing reference section? 'HC01' on line 238 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Bill Fenner, AT&T Research 3 INTERNET-DRAFT Haixiang He, Nortel Networks 4 draft-ietf-magma-igmp-proxy-00.txt Brian Haberman, Nortel Networks 5 Hal Sandick, Nortel Networks 6 Expire: May, 2002 November, 2001 8 IGMP-based Multicast Forwarding ("IGMP Proxying") 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 In certain topologies, it is not necessary to run a multicast routing 33 protocol. It is sufficient to learn and proxy group membership 34 information and simply forward based upon that information. This 35 draft describes a mechanism for forwarding based solely upon IGMP 36 membership information. 38 This document is a product of the IDMR working group within the 39 Internet Engineering Task Force. Comments are solicited and should 40 be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk 41 and/or the authors. 43 1. Introduction 45 This document applies spanning tree multicast routing[Deering91] to 46 an IGMP-only environment. The topology is limited to a tree, since 47 we specify no protocol to build a spanning tree over a more complex 48 topology. The root of the tree is assumed to be connected to a wider 49 multicast infrastructure. 51 1.1. Conventions 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [Bradner97]. 57 2. Definitions 59 2.1. Upstream Interface 61 A router's interface in the direction of the root of the tree. Also 62 called the "Host interface". 64 2.2. Downstream Interface 66 Each of a router's interfaces that is not in the direction of the 67 root of the tree. Also called the "Router interfaces". 69 2.3. Group Mode 71 For each multicast group, a group is in IGMPv1 mode if an IGMPv1 72 report is heard. A group is in IGMPv2 mode if an IGMPv2 report is 73 heard but no IGMPv1 report is heard. A group is in IGMPv3 mode if an 74 IGMPv3 is heard but no IGMPv1 or IGMPv2 report is heard. 76 2.4. Subscription 78 When a group is in IGMPv1 or IGMPv2 mode, the subscription is a group 79 membership on an interface. When a group is in IGMPv3 mode, the 80 subscription is an IGMPv3 state entry (i.e. a (multicast address, 81 group timer, filter-mode, source-element list) tuple) on an 82 interface. 84 2.5. Membership Database 86 The database maintained at each router into which the membership 87 information of each of its downstream interfaces is merged. 89 3. Abstract protocol definition 91 A router performing IGMP-based forwarding has a single upstream 92 interface and one or more downstream interfaces. These designations 93 are explicitly configured; there is no protocol to determine what 94 type each interface is. It performs the router portion of the IGMP 95 [Deering89, Fenner97, CDFKT01] protocol on its downstream interfaces, 96 and the host portion of IGMP on its upstream interface. The router 97 MUST NOT perform the router portion of IGMP on its upstream 98 interface. 100 The router maintains a database consisting of the merger of all 101 subscriptions on any downstream interface. Refer to section 4 for the 102 details about the construction and maintenance of the membership 103 database. 105 The router sends IGMP membership reports on the upstream interface 106 when queried, and sends unsolicited reports or leaves when the 107 database changes. 109 When the router receives a packet destined for a multicast group, it 110 uses a list consisting of the upstream interface and any downstream 111 interface which has a subscription pertaining to this packet and on 112 which it is the IGMP Querier. This list may be built dynamically or 113 cached. It removes the interface on which this packet arrived from 114 the list and forwards the packet to the remaining interfaces. 116 Note that the rule that a router must be the querier in order to 117 forward packets restricts the IP addressing scheme used; in 118 particular, the IGMP-based forwarding routers must be given the 119 lowest IP addresses of any potential IGMP Querier on the link, in 120 order to win the IGMP Querier election. If another device wins the 121 IGMP Querier election, no packets will flow. 123 Forwarder election is necessary for links which are considered to be 124 downstream links by multiple IGMP-based forwarders. This rule 125 "piggy-backs" forwarder election on IGMP Querier election. On a link 126 with only one IGMP-based forwarding router, this rule MAY be disabled 127 (i.e. the router MAY be configured to forward packets to an interface 128 on which it is not the querier). However, the default configuration 129 MUST include the querier rule. 131 Note that this does not protect against an "upstream loop". For 132 example, as shown in the figure below: 134 LAN 1 -------------------------------------- 135 Upstream | | Downstream 136 A B 137 Downstream | | Upstream 138 LAN 2 -------------------------------------- 140 B will unconditionally forward packets from LAN 1 to LAN 2, and A 141 will unconditionally forward packets from LAN 2 to LAN 1. This will 142 cause an upstream loop. A multicast routing protocol which employs a 143 tree building algorithm is requried to resolve loops like this. 145 3.1. Topology Restrictions 147 This specification describes a protocol that works only in a simple 148 tree topology. The tree must be manually configured by designating 149 upstream and downstream interfaces on each router, and the root of 150 the tree is expected to be connected to a wider multicast 151 infrastructure. 153 3.2. Supporting Senders 155 In order for senders to send from inside the proxy tree, all traffic 156 is forwarded towards the root. The multicast router(s) connected to 157 the wider multicast infrastructure should be configured to treat all 158 systems inside the proxy tree as though they were directly connected 159 -- e.g., for PIM-SM, these routers should Register-encapsulate 160 traffic from new sources within the proxy tree just as they would 161 directly-connected sources. 163 This information is likely to be manually configured; IGMP-based 164 multicast forwarding provides no way for the routers upstream of the 165 proxy tree to know what networks are connected to the proxy tree. If 166 the proxy topology is congruent with some routing topology, this 167 information MAY be learned from the routing protocol running on the 168 topology; e.g. a router may be configured to treat multicast packets 169 from all prefixes learned from routing protocol X via interface Y as 170 though they were from a directly connected system. 172 4. Router Behavior 173 This section describes an IGMP-based multicast forwarding router's 174 actions in more detail. 176 4.1. Membership Database 178 The router performs the router portion of the IGMP protocol on each 179 downstream interface. For each interface, the version of IGMP used 180 is explicitly configured and default to the highest version supported 181 by the system. 183 The output of this protocol is a set of subscriptions; this set is 184 maintained separately on each downstream interface. In addition, the 185 subscriptions on each downstream interface are merged into the 186 membership database. 188 The membership database is a set of membership records of the form: 190 (multicast-address, filter-mode, source-list) 192 Each record is the result of the merge of all subscriptions for that 193 record's multicast-address on downstream interfaces. If some 194 subscriptions are IGMPv1 or IGMPv2 subscriptions, these subscriptions 195 are converted to IGMPv3 subscriptions. The IGMPv3 subscriptions and 196 the converted subscriptions are merged using the merging rules for 197 multiple memberships on a single interface specified in the IGMPv3 198 specification[CDFKT01] to create the membership record. For example, 199 there are two downstream interfaces I1 and I2 that have subscriptions 200 for multicast address G. I1 has an IGMPv2 subscription that is (G). 201 I2 has an IGMPv3 subscription that is (G, INCLUDE, (S1, S2)). The 202 I1's subscription is converted to (G, EXCLUDE, NULL). Then the 203 subscriptions are merged and final membership record is (G, EXCLUDE, 204 NULL). 206 The router performs the host portion of the IGMP protocol on upstream 207 interface. If there is an IGMPv1 or IGMPv2 querier on upstream 208 network, then the router will perform IGMPv1 or IGMPv2 on upstream 209 interface accordingly. Otherwise, it will perform IGMPv3. 211 If the router performs IGMPv3 on upstream interface, then when the 212 composition of the membership database changes, the change in the 213 database is reported on the upstream interface as though this router 214 were a host performing the action. If the router performs IGMPv1 or 215 IGMPv2 on upstream interface, then when the membership records are 216 created or deleted, the changes are reported on the upstream 217 interface. All other changes are ignored. When the router reports 218 using IGMPv1 or IGMPv2, only the multicast address field in the 219 membership record is used. 221 4.2. Forwarding Packets 223 A router forwards packets received on its upstream interface to each 224 downstream interface based upon the downstream interface's 225 subscriptions and whether or not this router is the IGMP Querier on 226 each interface. A router forwards packets received on any downstream 227 interface to the upstream interface, and to each downstream interface 228 other than the incoming interface based upon the downstream 229 interfaces' subscriptions and whether or not this router is the IGMP 230 Querier on each interface. A router MAY use a forwarding cache in 231 order not to make this decision for each packet, but MUST update the 232 cache using these rules any time any of the information used to build 233 it changes. 235 4.3. SSM Considerations 237 To support Source-Specific Multicast (SSM), the router should be 238 compliant with the specification about using IGMPv3 for SSM [HC01]. 239 Note that the router should be compliant with both the IGMP Host 240 Requirement and the IGMP Router Requirement for SSM since it performs 241 IGMP Host Portion on upstream interface and IGMP Router Portion on 242 each downstream interface. 244 An interface can be configured to perform IGMPv1 or IGMPv2. In this 245 scenario, the SSM semantic will not be maintained for that interface. 246 However, a router that supports this document should ignore those 247 IGMPv1 or IGMPv2 subscriptions sent to SSM addresses. And more 248 importantly, the packets with source-specific addresses SHOULD not be 249 forwarded to interfaces with IGMPv2 or IGMPv1 subscriptions for these 250 addresses. 252 5. Security Considerations 254 Since only the Querier forwards packets, the IGMP Querier election 255 process may lead to black holes if a non-forwarder is elected 256 Querier. An attacker on a downstream LAN can cause itself to get 257 elected Querier resulting in no packets being forwarded. 259 References 261 Bradner97 Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", RFC 2119/BCP 14, Harvard 263 University, March 1997. 265 CDFKT01 Cain, B., S. Deering, B. Fenner, I. Kouvelas and A. 267 Thyagarajan, "Internet Group Management Protocol, 268 Version 3", Work in progress. (draft-ietf-idmr-igmp- 269 v3-07.txt) 271 Deering91 Deering, S., "Multicast Routing in a Datagram 272 Internetwork", Ph.D. Thesis, Stanford University, 273 December 1991. 275 Fenner97 Fenner, W., "Internet Group Management Protocol, 276 Version 2", RFC 2236, Xerox PARC, November 1997. 278 Deering89 Deering, S., "Host Extensions for IP Multicasting", 279 RFC 1112, August 1989. 281 HC01 Holbrook, H., and Cain, B., "Using IGMPv3 For Source- 282 Specific Multicast", draft-holbrook-idmr-igmpv3- 283 ssm-01.txt, March 2001. 285 Author's Address: 287 William C. Fenner 288 AT&T Labs - Research 289 75 Willow Rd 290 Menlo Park, CA 94025 291 Phone: +1 650 330 7893 292 Email: fenner@research.att.com 294 Haixiang He 295 Nortel Networks 296 600 Technology Park Drive 297 Billerica, MA 01821 298 Phone: 978-288-7482 299 Email: haixiang@nortelnetworks.com 301 Brian Haberman 302 Nortel Networks 303 300 Perimter Park 304 Morrisvile, NC 27560 305 Email: haberman@nortelnetworks.com 307 Hal Sandick 308 Nortel Networks 309 300 Perimter Park 310 Morrisvile, NC 27560 311 Email: hsandick@nortelnetworks.com