RFC 2337

RFC 2337: Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM 🦋

okay bestie, this one is an Experimental RFC from April 1998 🌸. It's by D. Farinacci, D. Meyer, and Y. Rekhter, and all three were at Cisco Systems. It doesn't obsolete or update anything (the header doesn't list any), so it's a standalone little experiment 💅. Let's get into it ✨

---

Status of this Memo 📋

okay so this memo defines an Experimental Protocol for the Internet community 🧪. It's not an Internet standard of any kind, so don't go treating it like one 🙈. They're asking for discussion and suggestions for improvement, and distribution of the memo is unlimited 💜.

Copyright Notice ©️

Copyright (C) The Internet Society (1998). All Rights Reserved. 🌈

2. Abstract ✨

okay so this doc explains how intra-LIS IP multicast can be supported efficiently among routers over ATM without using the Multicast Address Resolution Server (MARS) 🔥. The method is specific to Sparse Mode PIM [PIM-SM], and it relies on the explicit join mechanism that's built into PIM-SM. That join is how routers find out when they should create group-specific point-to-multipoint VCs 🦋.

3. Overall model 🧚

so this doc is all about forwarding multicast traffic among PIM-SM routers hooked up to an ATM network 💖. Routers on an ATM network get split up into Logical IP Subnets, aka LISs 🌸. This doc only deals with multicast inside a single LIS. Handling inter-LIS multicast traffic (shortcuts included) is outside the scope here, and the doc also doesn't cover forwarding multicast to or from hosts on an ATM network 🙅‍♀️.

4. Router behavior 🎀

this is the main event bestie 💅. The doc requires that each router within a LIS knows the IP and ATM addresses of every other router in that LIS. The IP-to-ATM mapping can come from an ARP server [RFC2225], or from any other means, like static configuration (e.g., static configuration) ⭐.

Each PIM router in a LIS is required to maintain a single (shared) point-to-multipoint distribution VC. That VC is rooted at the router, and all the other PIM routers in the LIS are its leaf nodes 🌈. The VC is expected to carry multicast traffic (both data and control) among the routers in the LIS 🫶. For example, this VC would be used to distribute PIM [PIM-SM] control messages, like Join/Prune messages 💜.

Also, if a PIM router gets an IGMP report from a non-PIM neighbor, the router may add the reporter to the existing shared distribution VC, or to the group-specific distribution VC if one exists ✨. The PIM router may also create a specific VC for this IGMP proxy 🧚.

4.1. Establishing Dedicated, Per Group Point-to-Multipoint VCs 🌸

okay so routers can also keep group-specific, dedicated point-to-multipoint VCs 🦋. An upstream router for a group may choose to become the root of a group-specific point-to-multipoint VC. Its leaves are the downstream routers that have directly connected receivers or downstream receivers for that group 💖. The criteria for setting one up are local to each router, but things like how much traffic goes with the group and the fanout factor within the LIS should be considered 👑. Last thing: a router must minimally support a single shared point-to-multipoint VC, used for distributing control messages and data (to all group addresses) 🫶.

A router can choose to set up a dedicated point-to-multipoint VC (or add another leaf to one that's already there) when it gets a PIM Join or an IGMP report from another device in the same LIS 🎀. When a router that's the root of a point-to-multipoint VC gets a PIM Prune message or an IGMP leave, it removes the originator from its dedicated point-to-multipoint VC 💅.

4.2. Switching to a Source-Rooted Tree 🌈

this part is so important 😭. If at least one router in a LIS decides to switch to a source-rooted tree (by sending (S,G) PIM Joins), then every other router in that LIS that has downstream members for G should switch to that tree too 🔥. A router that switches sends PIM Join messages for (S,G) over its shared point-to-multipoint VC, so the other routers in the LIS can detect it 👀. Once a router with downstream members for G detects this, it should also send an (S,G) PIM Join message. Otherwise it may receive duplicate traffic from S 💀.

Note that a non-PIM router in the LIS might fail to receive data if the injection point moves to a router that doesn't have an existing VC 🙈.

4.2.1. Adding New Members to a Source-Rooted Tree 🦋

like we said above, this doc requires that once one router in a LIS decides to switch to the source tree for some (S,G), every router in the LIS with downstream members must also switch to the (S,G) source tree 💖. Now, when a new router wants to receive traffic from G, it starts sending (*,G) Joins on its shared point-to-multipoint VC toward the RP for G 🧚. The root of the (S,G) source-rooted tree will know to add the new router to the point-to-multipoint VC serving that tree, because it sees the (*,G) Joins on the shared point-to-multipoint VC 👑. But the new router also has to switch to the (S,G) source-rooted tree itself. To do that, the newly added router must:

• (i). Notice that it has been added to a new point-to-multipoint VC 🌸
• (ii). Notice (S,G) traffic coming down this new point-to-multipoint VC 👀
• (iii). Send (S,G) joins toward S, causing it to switch to the source-rooted tree. The router learns that the VC is used to distribute (S,G) traffic in the previous steps 🫶

4.3. Handing the "Packet Reflection" Problem 🎀

when a router gets a multicast packet from another router in its own LIS, it should not send that packet on any of the router's distribution point-to-multipoint VCs associated with the LIS 🙅‍♀️. This gets rid of the "packet reflection" problem 🔥. Sending the packet on the router's distribution VCs associated with other LISs is controlled by the multicast routing procedures 🌈.

5. Brief Comparison with MARS 💅

the intra-LIS scheme in this doc is meant to be a less complex solution to an important subset of what MARS does [MARS] ✨. It's designed to give intra-LIS multicast between routers using PIM-SM, and it doesn't consider the case of host-rooted point-to-multipoint distribution VCs 🌸.

MARS supports both current schemes for mapping the IP multicast service model to ATM (multicast server, and meshes of point-to-multipoint VCs) 🦋. But it does so at a higher cost and complexity than the scheme in this doc 💸. MARS also requires new encapsulations, whereas this proposal works with either LLC/SNAP or NLPID encapsulation 🧚. Another big difference: MARS allows point-to-multipoint VCs rooted either at a source or at a multicast server (MCS). This approach keeps complexity down by focusing on PIM-SM (using the info in explicit joins), and by only letting point-to-multipoint VCs be rooted at the routers. That's roughly analogous to the complexity and functionality of rooting them at the sources 💖.

so in summary, this method is built for the router-to-router case, and it uses the explicit-join mechanism in PIM-SM to give a simple way to do intra-LIS multicast between routers 👑. MARS takes different tradeoffs in the complexity-functionality design space 🫶. The MARS paradigm does provide a general neighbor discovery mechanism, lets hosts participate, and is protocol independent. But it does all that at considerable cost 😭.

6. Security Considerations 🔥

okay this section is serious, so listen up 👀. In general, the security issues for the proposal in this memo are covered by the ones PIM-SM already faces 🛡️. Work is in progress on security for PIM-SM, but it's worth noting that several issues have come up with multicast routing, and with PIM-SM in particular 💀. These issues include, but are not limited to:

• (i). Unauthorized Senders 🚨
• (ii). Unauthorized Receivers 🚨
• (iii). Unauthorized use of the RP 🚨
• (iv). Unauthorized "last hop" switching to shortest path tree 🚨

6.1. General Comments on Multicast Routing Protocol Security 🔐

historically, routing protocols on the Internet have lacked strong authentication mechanisms [RFC1704] 😭. In the late 1980s, analysis showed a bunch of security problems in the Internet routing protocols then in use [BELLOVIN89]. During the early 1990s it became clear that adversaries were selectively attacking various intra-domain and inter-domain routing protocols (e.g., via TCP session stealing of BGP sessions) [CERTCA9501, RFC1636] 💀. More recently, cryptographic authentication mechanisms were developed for RIPv2, OSPF, and the proprietary EIGRP routing protocols 🔐. BGP protection, in the form of a Keyed MD5 option for TCP, has also become widely deployed 🌈.

At present, most multicast routing protocols lack strong cryptographic protection 🙈. One possible approach is to build a strong cryptographic protection mechanism (e.g., Keyed HMAC MD5 [RFC2104]) into the routing protocol itself 🛡️. Alternately, the routing protocol could be designed and specified to use the IP Authentication Header (AH) [RFC1825, RFC1826, RFC2085] to provide cryptographic authentication 🎀.

Because the intent of any routing protocol is to propagate routing information to other parties, confidentiality is not generally required in routing protocols 🧚. In the few cases where local security policy might require confidentiality, using the IP Encapsulating Security Payload (ESP) [RFC1825, RFC1827] is recommended 💖.

Scalable dynamic multicast key management is an active research area right now 🧪. Candidate technologies for it include CBT-based key management [RFC1949] and the Group Key Management Protocol (GKMP) [RFC2093,RFC2094] ✨. The IETF IP Security Working Group is actively working on GKMP extensions to the standards-track ISAKMP key management protocol, which is being developed in the same working group 👑.

7. References 📚✨

okay bestie, here's the reading list 🌸 every single one stays exactly as written:

• [BELLOVIN89] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, pp. 32-48, April 1989.
• [CERTCA9501] CERT, "IP Spoofing Attacks and Hijacked Terminal Connections", ftp://ftp.cert.org/cert_advisories/, January 1995.
• [MARS] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks.", RFC 2022, November 1996.
• [PIM-SM] Estrin, D, et. al., "Protocol Independent Multicast Sparse Mode (PIM-SM): Protocol Specification", Work in Progress.
• [RFC1636] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture February 8-10, 1994", RFC 1636, June 1994.
• [RFC1704] Haller, N., and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
• [RFC1825] Atkinson, R., "IP Security Architecture", RFC 1825, August 1995.
• [RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
• [RFC1827] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, August 1995.
• [RFC1949] Ballardie, A., "Scalable Multicast Key Distribution", RFC1949, June 1996.
• [RFC2085] Oehler, M., and R. Glenn, "HMAC-MD5 IP Authentication with Replay Prevention", RFC 2085, February 1997.
• [RFC2093] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
• [RFC2094] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.
• [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
• [RFC2225] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.

8. Acknowledgments 🫶

Petri Helenius gets all the flowers 💐 for giving several insightful comments on earlier versions of this document. Iconic behaviour ✨

9. Author Information 🎀

Meet the squad who wrote this 💜 Here are the three authors and their details, laid out exactly as they appear:

Dino Farinacci
Cisco Systems
170 Tasman Dr.
San Jose, CA 95134

Phone: (408) 526-4696
EMail: dino@cisco.com


David Meyer
Cisco Systems
170 Tasman Dr.
San Jose, CA 95134

Phone: (541) 687-2581
EMail: dmm@cisco.com


Yakov Rekhter
cisco Systems, Inc.
170 Tasman Dr.
San Jose, CA 95134

Phone: (914) 528-0090
EMail: yakov@cisco.com

10. Full Copyright Statement 💅

Now the legal bit 🙈 this part is the official text, so it stays word for word, no edits:

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.