RFC 9465

PIM Null-Register Packing

📅 published September 2023, from ietf

RFC 9465: PIM Null-Register Packing 🎀

okay bestie, this is the Standards Track doc from September 2023 💅 it's written by V. Kamath (VMware), R. Chokkanathapuram Sundaram (Cisco Systems, Inc.), R. Banthia (Apstra), and A. Gopal (Cisco Systems, Inc.). it's part of the IETF stream, so it's an official Internet standard and not just a suggestion ✨ it doesn't obsolete or update any other RFCs, so it stands on its own 🦋

Status of This Memo ✨

this is an Internet Standards Track document 💖

it's a product of the IETF and it's got the whole community's consensus behind it 🫶 it went through public review and got the green light from the IESG 🔥 if you want more on how Internet Standards work, check out Section 2 of RFC 7841 🧚

you can find the current status, errata, and a way to send feedback at https://www.rfc-editor.org/info/rfc9465 🌸

Copyright (c) 2023 IETF Trust and the document authors 💜 all rights reserved 🎀

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as of the publication date. please read those carefully, bestie, because they spell out your rights and restrictions 📜 any Code Components pulled out of this doc have to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Revised BSD License 💅

Table of Contents 🌈

1.  Introduction
  1.1.  Conventions Used in This Document
  1.2.  Terminology
2.  Packing Capability
3.  PIM Packed Null-Register Message Format
4.  PIM Packed Register-Stop Message Format
5.  Protocol Operation
6.  Operational Considerations
  6.1.  PIM Anycast RP Considerations
  6.2.  Interoperability between Different Versions
  6.3.  Disabling PIM Packed Message Support at RP and/or DR
7.  Fragmentation Considerations
8.  Security Considerations
9.  IANA Considerations
10. Normative References
Acknowledgments
Authors' Addresses

Abstract 🦋

okay so in PIM Sparse Mode (PIM-SM) networks, the Designated Router (DR) sends PIM Null-Register messages to the Rendezvous Point (RP) to say "hey, there are multicast sources out here" 📢 the DR keeps sending them on a timer so the RP keeps that state alive for as long as the source is active 💜 the catch is that each Null-Register only carries info for one multicast source and group pair 💀

this doc defines a way to send info about multiple sources and groups in a single PIM message 🔥 it calls the new messages the "PIM Packed Null-Register message" and the "PIM Packed Register-Stop message" 🧚

1. Introduction 💖

the DR periodically sends PIM Null-Registers to keep the existing multicast sources alive on the RP ✨ the more sources there are, the more Null-Registers get sent, and that means more PIM packet processing at both the RP and the DR 😭

this doc specifies an efficient way to pack the content of multiple PIM Null-Register and Register-Stop messages [RFC7761] into one message 🎀

it also talks about interoperability between PIM routers that support PIM Packed Null-Registers and PIM Packed Register-Stops, and PIM routers that don't 🫶

1.1. Conventions Used in This Document 🌸

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14 [RFC2119] [RFC8174] only when they're written in ALL CAPS, like here 🙈

1.2. Terminology 🍓

  • RP: Rendezvous Point
  • DR: Designated Router
  • MSDP: Multicast Source Discovery Protocol
  • PIM-SM: PIM Sparse Mode

2. Packing Capability 🧚

the RP tells the DR it can receive PIM Packed Null-Register messages (Section 3) and send PIM Packed Register-Stop messages (Section 4) using a Packing Capability bit (P-bit) in the PIM Register-Stop message 🦋 the P-bit gets its number in Section 9 👑

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |7 6 5 4 3 2 1|P|           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Group Address (Encoded-Group format)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Source Address (Encoded-Unicast format)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: PIM Register-Stop Message with Packing Capability Option 🎀

the Group Address and Source Address fields in the PIM Register-Stop message are defined in Section 4.9.4 of [RFC7761] 💅 the common header is defined in [RFC9436] 🌈

Packing Capability bit (P-bit; flag bit 0): when set, it means the RP can receive PIM Packed Null-Register messages and send PIM Packed Register-Stop messages ✨

3. PIM Packed Null-Register Message Format 💜

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |Subtype|  FB   |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Group Address[1]   (Encoded-Group format)                 |
|     Source Address[1]  (Encoded-Unicast format)               |
.                                                               .
.                                                               .
.                                                               .
.                                                               .
.     Group Address[N]                                          .
|     Source Address[N]                                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: PIM Packed Null-Register Message Format 🦋

the Group Address and Source Address fields in the PIM Packed Null-Register message are defined in Section 4.9.4 of [RFC7761] 🧚 the common header is defined in [RFC9436] 🫶

  • Type, Subtype: PIM Packed Null-Register (13.0) 💖
  • N: the total number of records. each record is one Group Address and Source Address pair ✨

after the PIM common header is parsed, the records get parsed one by one until the end of the PIM Packed Null-Register message 🎀 the length comes from the IP layer 🌸

sending or receiving a PIM Packed Null-Register message has the same effect as sending or receiving an individual Null-Register message for each record in it 🔥

4. PIM Packed Register-Stop Message Format 🌈

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |Subtype|  FB   |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Group Address[1]  (Encoded-Group format)                  |
|     Source Address[1]  (Encoded-Unicast format)               |
.                                                               .
.                                                               .
.                                                               .
.                                                               .
.     Group Address[N]                                          .
|     Source Address[N]                                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: PIM Packed Register-Stop Message Format 💅

the Group Address and Source Address fields in the PIM Packed Register-Stop message are defined in Section 4.9.4 of [RFC7761] 🦋 the common header is defined in [RFC9436] 💜

  • Type, Subtype: PIM Packed Register-Stop (13.1) 🍓
  • N: the total number of records. each record is one Group Address and Source Address pair 👑

after the PIM common header is parsed, the records get parsed one by one until the end of the PIM Packed Register-Stop message 🧚 the length comes from the IP layer 🫶

sending or receiving a PIM Packed Register-Stop message has the same effect as sending or receiving an individual Null-Register message for each record in the PIM Packed Register-Stop 🌸

5. Protocol Operation 🔥

okay so as [RFC7761] says, the DR sends PIM Register messages toward the RP whenever it spots a new source 👀

when this feature is enabled or configured, an RP that supports this spec MUST set the P-bit (flag bit 0) in every Register-Stop message 💖

when a Register-Stop with the P-bit set arrives, the DR SHOULD send PIM Packed Null-Register messages (Section 3) to the RP instead of a bunch of Register messages with the N-bit set [RFC7761] 💅 the DR MAY mix PIM Packed Null-Register messages and Register messages 🌈 that call is up to the implementation and out of scope for this doc 🙈 but it's RECOMMENDED to stick with the PIM Packed Null-Register and PIM Packed Register-Stop formats as long as the RP and DR have the feature enabled 🎀

after getting a PIM Packed Null-Register message, the RP SHOULD start sending PIM Packed Register-Stop messages (Section 4) to the matching DR instead of individual Register-Stop messages ✨ the RP MAY mix PIM Packed Register-Stop messages and individual Register-Stop messages 🦋 that's also up to the implementation and out of scope 🧚 but it's RECOMMENDED to stick with the PIM Packed Null-Register and PIM Packed Register-Stop formats as long as the RP and DR have the feature enabled 💜

6. Operational Considerations 🌸

6.1. PIM Anycast RP Considerations 🫶

the PIM Packed Null-Register packet format SHOULD only be enabled if all the routers in the Anycast-RP set support it [RFC4610] 🔥 this also applies to PIM Anycast RP with Multicast Source Discovery Protocol (MSDP) [RFC3446] 🍓

6.2. Interoperability between Different Versions 🍓

a router (DR) can pick the PIM Packed Null-Register message format based on the Packing Capability it gets from the RP in the PIM Register-Stop 🦋 this keeps things compatible with routers that can't handle the new packet format 🌈 the Packing Capability info MUST be indicated by the RP through the PIM Register-Stop message sent to the DR 💖 so a DR only switches to the new format once it learns the RP can handle PIM Packed Null-Register messages 👑

the other way round, a DR that doesn't support the packed format can keep generating the PIM Null-Register as defined in Section 4.4 of [RFC7761] 💅

(part 1 of 2, more coming next bestie 🧚💖)

6.3. Disabling PIM Packed Message Support at RP and/or DR ✨

Okay so, picture a PIM RP router that can do PIM Packed Null-Registers and PIM Packed Register-Stops. 🎀 Now it gets downgraded, or the feature just stops being supported for whatever reason. Then this router won't send a PIM Register-Stop message to the DR in response to a PIM Packed Null-Register message. Ghosted, bestie 💀

When the DR switches from Null-Registers to Data Registers, it MUST start a Packed_Register_Probe_Time timer. 🧚 If no PIM Packed Register-Stop or Register-Stop with the P-bit set shows up before Packed_Register_Probe_Time seconds are up, the DR can decide that the RP no longer supports PIM Packed Null-Registers. The Packed_Register_Probe_Time timer is configurable, and its default value is 60 seconds. ⏱️

When Packed_Register_Probe_Time expires, the DR MAY also send an unpacked PIM Null-Register and check the PIM Register-Stop to see whether the P-bit is set. If it isn't set, the DR will just keep sending unpacked PIM Null-Register messages. Very cautious, very iconic 🫶

Now, if the network manager disables the Packing Capability at the RP (or in other words, turns the feature off from the RP side), the router MUST NOT advertise the Packing Capability. 🚫 BUT, an implementation MAY choose to still parse any packed registers it receives. This can be super useful in the transitional period right after the network manager flips the switch 🌈

7. Fragmentation Considerations 🦋

Okay, so as explained in Section 4.4.1 of [RFC7761], the DR may perform Path MTU Discovery to the RP before it sends PIM Packed Null-Register messages. Similarly, the RP may perform Path MTU Discovery to the DR before it sends PIM Packed Register-Stop messages. 🌸 In both cases, the number of records in a message should be limited so that it can fit within the Path MTU. Keep those packets small enough to fit, babe 💅

8. Security Considerations 🔥

The Security Considerations in [RFC7761] apply to this document. 🔒 In particular, if someone forges a PIM Packed Null-Register or Register-Stop message, the effect gets amplified to all the records included instead of just one. Yikes. That's a whole chaos situation 💀

By forging a PIM Register-Stop message and setting the P-bit, an attacker can trigger the use of PIM Packed Null-Register messages by a DR, thus creating unnecessary churn in the network. 😭 Literally the main character villain arc, so don't let it happen 👑

9. IANA Considerations 🍓

IANA has assigned a Packing Capability bit (0) in the PIM Register-Stop common header in the "PIM Message Types" registry. 🎀

IANA has assigned a PIM message type (13.0) for PIM Packed Null-Register in the "PIM Message Types" registry. The flag bits 0-3 for this message type are "Unassigned". 💜

IANA has also assigned a PIM message type (13.1) for PIM Packed Register-Stop in the "PIM Message Types" registry. The flag bits 0-3 for this message type are "Unassigned". ✨

10. Normative References 📚

Acknowledgments 🫶

The authors would like to thank Stig Venaas, Alvaro Retana, Anish Peter, Zheng Zhang, and Umesh Dudani for their helpful comments on the document. Huge thanks to all of them, they really came through 🌈👑

Authors' Addresses 🌸

Vikas Ramesh Kamath
VMware
3401 Hillview Ave
Palo Alto, CA 94304
United States of America
Email: vkamath@vmware.com


Ramakrishnan Chokkanathapuram Sundaram
Cisco Systems, Inc.
Tasman Drive
San Jose, CA 95134
United States of America
Email: ramaksun@cisco.com


Raunak Banthia
Apstra
Suite 200
333 Middlefield Rd
Menlo Park, CA 94025
United States of America
Email: rbanthia@apstra.com


Ananya Gopal
Cisco Systems, Inc.
Tasman Drive
San Jose, CA 95134
United States of America
Email: ananygop@cisco.com
📦 where this page comes from