RFC 4602

Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis

📅 published August 2006, from ietf

RFC 4602: Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis 💖

okay bestie, RFC 4602 is giving receipts that prove a protocol is ready for the big leagues 🎀. It's by T. Pusateri at Juniper Networks, filed under the Network Working Group, and it's an Informational doc dated August 2006 📅. This one isn't a standard itself. It's the supporting paperwork for PIM-SM. The header doesn't list anything it obsoletes or updates, so no drama there ✨.

Status of This Memo 🧾

this memo is just here to share info with the Internet community 💅. it doesn't specify an Internet standard of any kind, and it can be distributed without limits 🌈.

Copyright (C) The Internet Society (2006).

Abstract 🌸

this doc is backup for moving the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Experimental status up to Proposed Standard 🚀. it's the glow-up arc 💫.

Table of Contents 📚

   1. Introduction ....................................................2
   2. RFC 1264 Requirements ...........................................2
      2.1. Documents Specifying the Protocol and Its Usage ............2
      2.2. Management Information Base ................................2
      2.3. Explicit Security Architecture .............................2
      2.4. Implementation Existence ...................................3
           2.4.1. XORP ................................................3
           2.4.2. Cisco IOS/IOX .......................................3
           2.4.3. Infosys Technologies, Ltd. ..........................3
           2.4.4. Procket Networks ....................................3
      2.5. Evidence of Testing ........................................4
           2.5.1. Cisco ...............................................4
           2.5.2. XORP ................................................4
           2.5.3. Procket Networks ....................................5
      2.6. Suitability ................................................5
      2.7. Authentication Mechanisms ..................................5
   3. Security Considerations .........................................5
   4. Acknowledgements ................................................5
   5. References ......................................................6
      5.1. Normative References .......................................6
      5.2. Informative References .....................................6

1. Introduction 🦋

okay so this analysis is the supporting doc for upgrading PIM-SM from IETF Experimental status to Proposed Standard 💅. PIM-SM first showed up as RFC 2117 [RFC2117] in 1997, then again as RFC 2362 [RFC2362] in 1998 🍓. both of those were labeled Experimental. then the PIM-SM spec got fully rewritten so it could explain the protocol way more thoroughly ✨. that new version is the one that's up for Proposed Standard, and it's giving main character energy 👑.

2. RFC 1264 Requirements 🎀

Section 4.0 of RFC 1264 [RFC1264] lists what a routing protocol needs before it can move up to Proposed Standard 📝. every requirement is below with a breakdown of how it got met, so you can see the receipts 🧾🫶.

2.1. Documents Specifying the Protocol and Its Usage 📖

the authors of the new PIM-SM spec [RFC4601] were super intentional about fully explaining how the protocol works 🫶. they cleared up all the known ambiguities and tried to tidy up the weird corner cases from the old spec 🧹. it's already been used to build several interoperable implementations by developers who didn't write the spec, which is lowkey the best proof 🔥. those implementations are described below 👇.

2.2. Management Information Base 🗂️

a Management Information Base for PIM is currently specified in RFC 2934 [RFC2934] ✨. this MIB has tons of implementations and network management apps have been using it for years 💜. updates to support IPv6 and other improvements based on operational experience are in progress in the PIM Working Group of the IETF 🧚.

2.3. Explicit Security Architecture 🔐

the new PIM Sparse-Mode spec has a big security section that explains its security features and its limits 🙈. data integrity protection and groupwise data origin authentication are provided for PIM protocol messages 🛡️. no cap, that's a whole vibe 💖.

2.4. Implementation Existence 🌈

there are at least 4 known independent implementations of the new protocol spec 🙌, and over 6 independent implementations of the previous version (RFC 2362) 😭. the new spec was carefully written to be backward compatible with the old one, so implementations compliant with RFC 2362 can also be compliant with the new spec 🫶.

the 4 implementations of the new version are described below ✨.

2.4.1. XORP 🦋

the XORP project [XORP] has an open-source implementation of PIM-SM v2 as specified in RFC 4601 💅. it was written by Pavlin Radoslavov <pavlin@icir.org> and has been available to the public since December 2002 🎀. Pavlin is not an author of the protocol spec. and it doesn't use any other existing code as a base 🧚.

2.4.2. Cisco IOS/IOX 🌸

Cisco Systems, Inc., wrote an implementation of the new protocol spec that's been deployed in production routers 🔥. there's an IOS implementation for IPv6 only, and an IOX implementation for both IPv4 and IPv6 💜. this code was first written by Isidor Kouvelas <kouvelas@cisco.com> 👑. it doesn't depend on any existing code base. and Isidor is a co-author of the protocol spec 🫶.

2.4.3. Infosys Technologies, Ltd. 🍓

Infosys Technologies, Ltd. (www.infosys.com) built a limited shared-tree implementation of the new Sparse-Mode spec ✨. it covers PIM Hello messages, DR election, PIM join/prune messages, join suppression, and prune override 💅. Bharat Joshi <bharat_joshi@infosys.com> wrote it, and it's used in commercial products 🌈. Bharat is not an author of the protocol spec 💖.

2.4.4. Procket Networks 🧚

an implementation was written from scratch at Procket Networks by Dino Farinacci <dino@cisco.com> 🙈. it's now owned by Cisco Systems, Inc. 💀. and Dino is not an author of the new protocol spec 🎀.

Author's Address ✨

okay so this is where we find out who wrote it 🎀 Tom Pusateri from Juniper Networks, and here's how to reach him if you need to 💌

Tom Pusateri
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA  94089
USA

Phone: +1 408 745 2000
EMail: pusateri@juniper.net

Copyright (C) The Internet Society (2006). 🦋

Okay, so this whole document is covered by the rights, licenses and restrictions in BCP 78 🔒 and, except for what BCP 78 says, the authors keep all their rights. Bestie, that's just legal stuff, but it matters 🙈

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 💀

Intellectual Property 🌈

So the IETF is not picking a side here 🙅‍♀️ It doesn't say whether any patents or other proprietary rights that might cover this tech are valid or how far they reach, and it doesn't say whether you could get a license for them either. It also hasn't gone hunting for those rights itself, so don't assume it did 👀 If you want to dig into the rules for rights in RFC documents, check out BCP 78 and BCP 79 🔍

Copies of IPR disclosures sent to the IETF Secretariat are a thing, and so are assurances of licenses, plus the results of any attempt to get a general license or permission to use proprietary rights for implementing or using this specification. You can get all of that from the IETF's online IPR repository at http://www.ietf.org/ipr ✨

Also, if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard, please tell the IETF about them 🫶 Send that to ietf-ipr@ietf.org 💜

Acknowledgement 🌸

Shoutout to the people keeping the lights on! ⭐ Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 👑

📦 where this page comes from