idnits 2.17.1 draft-ietf-magma-igmp-proxy-06.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 11 longer pages, the longest (page 3) being 76 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 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.) ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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.) -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'MLDv2' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSM' Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MAGMA Working Group Bill Fenner, AT&T Research 2 INTERNET-DRAFT Haixiang He, Nortel Networks 3 draft-ietf-magma-igmp-proxy-06.txt Brian Haberman, Caspian Networks 4 Hal Sandick, Sheperd Middle School 5 Expire: October, 2004 April, 2004 7 IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying") 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 In certain topologies, it is not necessary to run a multicast routing 32 protocol. It is sufficient for a device to learn and proxy group 33 membership information and simply forward multicast packets based 34 upon that information. This draft describes a mechanism for 35 forwarding based solely upon Internet Group Management Protocol 36 (IGMP) or Multicast Listener Discovery (MLD) membership information. 38 1. Introduction 40 This document applies spanning tree multicast routing [MCAST] to an 41 Internet Group Management Protocol (IGMP) or Multicast Listener 42 Discovery (MLD) only environment. The topology is limited to a tree, 43 since we specify no protocol to build a spanning tree over a more 44 complex topology. The root of the tree is assumed to be connected to 45 a wider multicast infrastructure. 47 1.1. Motivation 49 In a simple tree topology, it is not necessary to run a multicast 50 routing protocol. It is sufficient to learn and proxy group 51 membership information and simply forward multicast packets based 52 upon that information. One typical example of such tree topology can 53 be found on an edge aggregation box such as Digital Subscriber Line 54 Access Multiplexer (DSLAM). In most deployment scenarios, an edge box 55 has only one connection to the core network side and has many 56 connections to the customer side. 58 Using IGMP/MLD-based forwarding to replicate multicast traffic on 59 devices such as the edge boxes can greatly simplify the design and 60 implementation of those devices. By not supporting more complicated 61 multicast routing protocols such as Protocol Independent Multicast 62 (PIM) or Distance Vector Multicast Routing Protocol (DVMRP), it 63 reduces not only the cost of the devices but also the operational 64 overhead. Another advantage is that it makes the proxy devices 65 independent of the multicast routing protocol used by the core 66 network routers. Hence proxy devices can be easily deployed in any 67 multicast network. 69 Robustness in an edge box is usually achieved by using a hot spare 70 connection to the core network. When the first connection fails, the 71 edge box fails over to the second connection. IGMP/MLD-based 72 forwarding can benefit from such mechanism and use the spare 73 connection for its redundant or backup connection to multicast 74 routers. When an edge box fails over to the second connection, the 75 proxy upstream connection can also be updated to the new connection. 77 1.2. Applicability Statement 79 The IGMP/MLD-based forwarding only works in a simple tree topology. 80 The tree must be manually configured by designating upstream and 81 downstream interfaces on each proxy device. In addition, the IP 82 addressing scheme applied to the proxying tree topology SHOULD be 83 configured to ensure a proxy device can win the IGMP/MLD Querier 84 election to be able to forward multicast traffic. There are no other 85 multicast routers except the proxy devices within the tree and the 86 root of the tree is expected to be connected to a wider multicast 87 infrastructure. This protocol is limited to a single administrative 88 domain. 90 In more complicated scenarios where the topology is not a tree, a 91 more robust failover mechanism is desired, or more than one 92 administrative domains are involved, a multicast routing protocol 93 should be used. 95 1.3. Conventions 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC 2119]. 101 This document is a product of the Multicast & Anycast Group 102 Membership (MAGMA) working group within the Internet Engineering Task 103 Force. Comments are solicited and should be addressed to the working 104 group's mailing list at magma@ietf.org and/or the authors. 106 2. Definitions 108 2.1. Upstream Interface 110 A proxy device's interface in the direction of the root of the tree. 111 Also called the "Host interface". 113 2.2. Downstream Interface 115 Each of a proxy device's interfaces that is not in the direction of 116 the root of the tree. Also called the "Router interfaces". 118 2.3. Group Mode 120 In IPv4 environments, for each multicast group, a group is in IGMP 121 version 1 (IGMPv1) [RFC 1112] mode if an IGMPv1 report is heard. A 122 group is in IGMP version 2 (IGMPv2) [RFC 2236] mode if an IGMPv2 123 report is heard but no IGMPv1 report is heard. A group is in IGMP 124 version 3 (IGMPv3) [RFC 3376] mode if an IGMPv3 report is heard but 125 no IGMPv1 or IGMPv2 report is heard. 127 In IPv6 environments, for each multicast group, a group is in MLD 128 version 1 (MLDv1) [RFC 2710] mode if a MLDv1 report is heard. MLDv1 129 is equivalent to IGMPv2. A group is in MLD version 2 (MLDv2) [MLDv2] 130 mode if an MLDv2 report is heard but no MLDv1 report is heard. MLDv2 131 is equivalent to IGMPv3. 133 2.4. Subscription 135 When a group is in IGMPv1 or IGMPv2/MLDv1 mode, the subscription is a 136 group membership on an interface. When a group is in IGMPv3/MLDv2 137 mode, the subscription is an IGMPv3/MLDv2 state entry (i.e. a 138 (multicast address, group timer, filter-mode, source-element list) 139 tuple) on an interface. 141 2.5. Membership Database 143 The database maintained at each proxy device into which the 144 membership information of each of its downstream interfaces is 145 merged. The membership database is a set of membership records of the 146 form: 148 (multicast-address, filter-mode, source-list) 150 Please refer to IGMPv3/MLDv2 [RFC 3376, MLDv2] specifications for the 151 definition of the fields "filter-mode" and "source-list". The 152 operational behaviors of the membership database is defined in 153 section 4.1. 155 3. Abstract protocol definition 157 A proxy device performing IGMP/MLD-based forwarding has a single 158 upstream interface and one or more downstream interfaces. These 159 designations are explicitly configured; there is no protocol to 160 determine what type each interface is. It performs the router 161 portion of the IGMP [RFC 1112, RFC 2236, RFC 3376] or MLD [RFC 2710, 162 MLDv2] protocol on its downstream interfaces, and the host portion of 163 IGMP/MLD on its upstream interface. The proxy device MUST NOT 164 perform the router portion of IGMP/MLD on its upstream interface. 166 The proxy device maintains a database consisting of the merger of all 167 subscriptions on any downstream interface. Refer to section 4 for the 168 details about the construction and maintenance of the membership 169 database. 171 The proxy device sends IGMP/MLD membership reports on the upstream 172 nterface when queried, and sends unsolicited reports or leaves when 173 the database changes. 175 When the proxy device receives a packet destined for a multicast 176 group (channel in Source-Specific Multicast (SSM)), it uses a list 177 consisting of the upstream interface and any downstream interface 178 which has a subscription pertaining to this packet and on which it is 179 the IGMP/MLD Querier. This list may be built dynamically or cached. 180 It removes the interface on which this packet arrived from the list 181 and forwards the packet to the remaining interfaces (this may include 182 the upstream interface). 184 Note that the rule that a proxy device must be the querier in order 185 to forward packets restricts the IP addressing scheme used; in 186 particular, the IGMP/MLD-based forwarding devices must be given the 187 lowest IP addresses of any potential IGMP/MLD Querier on the link, in 188 order to win the IGMP/MLD Querier election. IGMP/MLD Querier election 189 rule defines that the Querier that has the lowest IP address wins the 190 election (The IGMP/MLD Querier election rule is defined in IGMP/MLD 191 specifications as part of the IGMP/MLD behavior). So in an IGMP/MLD- 192 based forwarding only environment, if non proxy device wins the 193 IGMP/MLD Querier election, no packets will flow. 195 For example, in an IGMP/MLD-based forwarding only environment as 196 shown in the figure below: 198 LAN 1 -------------------------------------- 199 Upstream | | Upstream 200 A(non-proxy) B(proxy) 201 Downstream |(lowest IP) | Downstream 202 LAN 2 -------------------------------------- 204 device A has the lowest IP address on LAN 2 but it is not a proxy 205 device. According to IGMP/MLD Querier election rule, A will win the 206 election on LAN 2 since it has the lowest IP address. Device B will 207 not forward traffic to LAN 2 since it is not the querier on LAN 2. 209 The election of a single forwarding proxy is necessary to avoid local 210 loops and redundant traffic for links which are considered to be 211 downstream links by multiple IGMP/MLD-based forwarders. This rule 212 "piggy-backs" forwarder election on IGMP/MLD Querier election. The 213 use of the IGMP/MLD Querier election process to choose the forwarding 214 proxy delivers similar functionality on the local link as the PIM 215 Assert mechanism. On a link with only one IGMP/MLD-based forwarding 216 device, this rule MAY be disabled (i.e. the device MAY be configured 217 to forward packets to an interface on which it is not the querier). 218 However, the default configuration MUST include the querier rule. 220 For example, for redundancy purpose, as shown in the figure below: 222 LAN 1 -------------------------------------- 223 Upstream | | Upstream 224 A B 226 Downstream | | Downstream 227 LAN 2 -------------------------------------- 229 LAN 2 can have two proxy devices A and B. In such configuration, one 230 proxy device must be elected to forward the packets. This document 231 requires that the forwarder must be the IGMP/MLD querier. So proxy 232 device A will forward packets to LAN 2 only if A is the querier. In 233 the above figure, if A is the only proxy device, A can be configured 234 to forward packets even though B is the querier. 236 Note that this does not protect against an "upstream loop". For 237 example, as shown in the figure below: 239 LAN 1 -------------------------------------- 240 Upstream | | Downstream 241 A B 242 Downstream | | Upstream 243 LAN 2 -------------------------------------- 245 B will unconditionally forward packets from LAN 1 to LAN 2, and A 246 will unconditionally forward packets from LAN 2 to LAN 1. This will 247 cause an upstream loop. A multicast routing protocol which employs a 248 tree building algorithm is required to resolve loops like this. 250 3.1. Topology Restrictions 252 This specification describes a protocol that works only in a simple 253 tree topology. The tree must be manually configured by designating 254 upstream and downstream interfaces on each proxy device, and the root 255 of the tree is expected to be connected to a wider multicast 256 infrastructure. 258 3.2. Supporting Senders 260 In order for senders to send from inside the proxy tree, all traffic 261 is forwarded towards the root. The multicast router(s) connected to 262 the wider multicast infrastructure should be configured to treat all 263 systems inside the proxy tree as though they were directly connected 264 -- e.g., for Protocol Independent Multicast - Sparse Mode (PIM-SM) 265 [PIM-SM], these routers should Register-encapsulate traffic from new 266 sources within the proxy tree just as they would directly-connected 267 sources. 269 This information is likely to be manually configured; IGMP/MLD-based 270 multicast forwarding provides no way for the routers upstream of the 271 proxy tree to know what networks are connected to the proxy tree. If 272 the proxy topology is congruent with some routing topology, this 273 information MAY be learned from the routing protocol running on the 274 topology; e.g. a router may be configured to treat multicast packets 275 from all prefixes learned from routing protocol X via interface Y as 276 though they were from a directly connected system. 278 4. Proxy Device Behavior 280 This section describes an IGMP/MLD-based multicast forwarding 281 device's actions in more detail. 283 4.1. Membership Database 285 The proxy device performs the router portion of the IGMP/MLD protocol 286 on each downstream interface. For each interface, the version of 287 IGMP/MLD used is explicitly configured and defaults to the highest 288 version supported by the system. 290 The output of this protocol is a set of subscriptions; this set is 291 maintained separately on each downstream interface. In addition, the 292 subscriptions on each downstream interface are merged into the 293 membership database. 295 The membership database is a set of membership records of the form: 297 (multicast-address, filter-mode, source-list) 299 Each record is the result of the merge of all subscriptions for that 300 record's multicast-address on downstream interfaces. If some 301 subscriptions are IGMPv1 or IGMPv2/MLDv1 subscriptions, these 302 subscriptions are converted to IGMPv3/MLDv2 subscriptions. The 303 IGMPv3/MLDv2 and the converted subscriptions are first preprocessed 304 to remove the timers in the subscriptions, and if the filter mode is 305 EXCLUDE, to remove every source whose source timer > 0. Then the 306 preprocessed subscriptions are merged using the merging rules for 307 multiple memberships on a single interface specified in section 3.2 308 of the IGMPv3 specification [RFC 3376] and in section 4.2 of the 309 MLDv2 specification [MLDv2] to create the membership record. For 310 example, there are two downstream interfaces I1 and I2 that have 311 subscriptions for multicast address G. I1 has an IGMPv2/MLDv1 312 subscription that is (G). I2 has an IGMPv3/MLDv2 subscription that 313 has membership information (G, INCLUDE, (S1, S2)). The I1's 314 subscription is converted to an IGMPv3/MLDv2 subscription that has 315 membership information (G, EXCLUDE, NULL). Then the subscriptions are 316 preprocessed and merged and final membership record is (G, EXCLUDE, 317 NULL). 319 The proxy device performs the host portion of the IGMP/MLD protocol 320 on the upstream interface. If there is an IGMPv1 or IGMPv2/MLDv1 321 querier on the upstream network, then the proxy device will perform 322 IGMPv1 or IGMPv2/MLDv1 on the upstream interface accordingly. 323 Otherwise, it will perform IGMPv3/MLDv2. 325 If the proxy device performs IGMPv3/MLDv2 on the upstream interface, 326 then when the composition of the membership database changes, the 327 change in the database is reported on the upstream interface as 328 though this proxy device were a host performing the action. If the 329 proxy device performs IGMPv1 or IGMPv2/MLDv1 on the upstream 330 interface, then when the membership records are created or deleted, 331 the changes are reported on the upstream interface. All other 332 changes are ignored. When the proxy device reports using IGMPv1 or 333 IGMPv2/MLDv1, only the multicast address field in the membership 334 record is used. 336 4.2. Forwarding Packets 338 A proxy device forwards packets received on its upstream interface to 339 each downstream interface based upon the downstream interface's 340 subscriptions and whether or not this proxy device is the IGMP/MLD 341 Querier on each interface. A proxy device forwards packets received 342 on any downstream interface to the upstream interface, and to each 343 downstream interface other than the incoming interface based upon the 344 downstream interfaces' subscriptions and whether or not this proxy 345 device is the IGMP/MLD Querier on each interface. A proxy device MAY 346 use a forwarding cache in order not to make this decision for each 347 packet, but MUST update the cache using these rules any time any of 348 the information used to build it changes. 350 4.3. SSM Considerations 352 To support Source-Specific Multicast (SSM), the proxy device should 353 be compliant with the specification about using IGMPv3 for SSM [SSM]. 354 Note that the proxy device should be compliant with both the IGMP 355 Host Requirement and the IGMP Router Requirement for SSM since it 356 performs IGMP Host Portion on the upstream interface and IGMP Router 357 Portion on each downstream interface. 359 An interface can be configured to perform IGMPv1 or IGMPv2. In this 360 scenario, the SSM semantic will not be maintained for that interface. 361 However, a proxy device that supports this document should ignore 362 those IGMPv1 or IGMPv2 subscriptions sent to SSM addresses. And more 363 importantly, the packets with source-specific addresses SHOULD NOT be 364 forwarded to interfaces with IGMPv2 or IGMPv1 subscriptions for these 365 addresses. 367 5. Security Considerations 369 Since only the Querier forwards packets, the IGMP/MLD Querier 370 election process may lead to black holes if a non-forwarder is 371 elected Querier. An attacker on a downstream LAN can cause itself to 372 be elected Querier resulting in no packets being forwarded. However, 373 there are some operational ways to avoid this problem. It is fairly 374 common for an operator to number the routers starting from the bottom 375 of the subnet. So an operator SHOULD assign the subnet's lowest IP 376 address(es) to a proxy (proxies) in order for the proxy (proxies) to 377 win the querier election. 379 IGMP/MLD-based forwarding does not provide "upstream loop" detection 380 mechanism as described in section 3. Hence to avoid the problems 381 caused by an "upstream loop", it MUST be administratively assured 382 that such loops don't exist when deploying IGMP/MLD Proxying. 384 The IGMP/MLD information presented by the proxy to its upstream 385 routers is the aggregation of all its downstream group membership 386 information. Any access control applied on the group membership 387 protocol at the upstream router can not be performed on a single 388 subscriber. That is, the access control will apply equally to all the 389 interested hosts reachable via the proxy device. 391 Acknowledgments 393 The authors would like to thank Erik Nordmark, Dave Thaler, Pekka 394 Savola, Karen Kimball and others for reviewing the specification and 395 providing their comments. 397 Normative References 399 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", RFC 2119/BCP 14, Harvard 401 University, March 1997. 403 [RFC 3376] Cain, B., S. Deering, B. Fenner, I. Kouvelas and A. 404 Thyagarajan, "Internet Group Management Protocol, 405 Version 3", RFC 3376, October 2002. 407 [RFC 2236] Fenner, W., "Internet Group Management Protocol, 408 Version 2", RFC 2236, Xerox PARC, November 1997. 410 [RFC 1112] Deering, S., "Host Extensions for IP Multicasting", 411 RFC 1112, August 1989. 413 [RFC 2710] Deering, S., Fenner, W., and Haberman, B., "Multicast 414 Listener Discovery (MLD) for IPv6", RFC 2710, 415 October 1999. 417 [MLDv2] Vida, R., Costa and L., Fdida, "Multicast Listener 419 Discovery Version 2 (MLDv2) for IPv6", Work in Progress. 421 [SSM] Holbrook, H., Cain, B., and Haberman, B., "Using IGMPv3 422 and MLDv2 for Source-Specific Multicast", Work in Progress. 424 Informative References 426 [MCAST] Deering, S., "Multicast Routing in a Datagram 427 Internetwork", Ph.D. Thesis, Stanford University, 428 December 1991. 430 [PIM-SM] Fenner, W., Handley, M., Holbrook, H., and Kouvelas, I., 431 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 432 Protocol Specification (Revised)", Work in Progress. 434 Author's Address: 436 William C. Fenner 437 AT&T Labs - Research 438 75 Willow Rd 439 Menlo Park, CA 94025 440 Phone: +1 650 330 7893 441 Email: fenner@research.att.com 443 Haixiang He 444 Nortel Networks 445 600 Technology Park Drive 446 Billerica, MA 01821 447 Phone: +1 978 288 7482 448 Email: haixiang@nortelnetworks.com 450 Brian Haberman 451 Caspian Networks 452 One Park Drive, Suite 400 453 Research Triangle Park, NC 27709 454 Phone: +1 919 949 4828 455 Email: bkhabs@nc.rr.com 457 Hal Sandick 458 Sheperd Middle School 459 2401 Dakota St. 460 Durham, NC 27707 461 Email: sandick@nc.rr.com 463 Full Copyright Statement 465 Copyright (C) The Internet Society (2002). All Rights Reserved. 467 This document and translations of it may be copied and furnished to 468 others, and derivative works that comment on or otherwise explain it 469 or assist in its implementation may be prepared, copied, published 470 and distributed, in whole or in part, without restriction of any 471 kind, provided that the above copyright notice and this paragraph are 472 included on all such copies and derivative works. However, this 473 document itself may not be modified in any way, such as by removing 474 the copyright notice or references to the Internet Society or other 475 Internet organizations, except as needed for the purpose of 476 developing Internet standards in which case the procedures for 477 copyrights defined in the Internet Standards process must be 478 followed, or as required to translate it into languages other than 479 English. 481 The limited permissions granted above are perpetual and will not be 482 revoked by the Internet Society or its successors or assigns. 484 This document and the information contained herein is provided on an 485 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 486 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 487 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 488 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 489 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 491 Acknowledgement: 493 Funding for the RFC Editor function is currently provided by the 494 Internet Society.