RFC 6166 PROPOSED STANDARD ROUTING · REGISTRY

PIM Message Registry: A Registry for PIM Message Types

A central registry for Protocol Independent Multicast message types.

On rfc-editor.org ↗
PUBLISHED
April 2011
AUTHORS
S. Venaas
STREAM
IETF
OBSOLETED BY
RFC 8736 — PIM type space extension
MESSAGE TYPE FIELD
4 bits
POSSIBLE VALUES
0 to 15
ASSIGNED TYPES
10
DOI
10.17487/RFC6166

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Internet Engineering Task Force (IETF)                         S. Venaas
Request for Comments: 6166                                 Cisco Systems
Category: Standards Track                                     April 2011
ISSN: 2070-1721


                    A Registry for PIM Message Types

Abstract

   This document provides instructions to IANA for the creation of a
   registry for PIM message types.  It specifies the initial content of
   the registry, based on existing RFCs specifying PIM message types.
   It also specifies a procedure for registering new types.

   In addition to this, one message type is reserved, and may be used
   for a future extension of the message type space.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6166.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................2
   2. Security Considerations .........................................2
   3. IANA Considerations .............................................2
      3.1. Initial Registry ...........................................3
      3.2. Assignment of New Message Types ............................3
   4. Acknowledgements ................................................3
   5. Informative References ..........................................3

1.  Introduction

   Apart from this document, there is no existing document specifying a
   registry for PIM message types.  PIM version 1 made use of IGMP
   [RFC1112], and there is an IGMP registry [IGMPREG] listing the
   message types used by PIM version 1.  PIM version 2, however, is not
   based on IGMP, and a separate PIM message type registry is needed.
   There are currently several RFCs specifying new PIM version 2 message
   types that should be in this new registry.  They are the RFCs for PIM
   Dense Mode [RFC3973], PIM Sparse Mode [RFC4601], and Bidirectional
   PIM [RFC5015].

   This document specifies the initial content of the new PIM message
   type registry, based on those existing RFCs.  This document also
   specifies a procedure for registering new PIM message types.

   In addition to this, this document reserves one message type.  This
   type may be used for a future extension of the message type space.
   The current message type space is only 4 bits, so it is not unlikely
   that this will be needed.  How exactly the extension should be done
   is left to a future document.

2.  Security Considerations

   This document only creates an IANA registry.  There may be a security
   benefit in a well-known place for finding information on which PIM
   message types are valid and how they are used.  Apart from that,
   there are no security considerations.

3.  IANA Considerations

   IANA has created a PIM message type registry.  It has been placed in
   the "Protocol Independent Multicast (PIM)" branch of the tree.  Each
   entry in the registry consists of a message type, a message name, and
   references to the documents defining the type.  The message type is a
   4-bit integer with possible values from 0 to 15.

3.1.  Initial Registry

   The initial content of the registry should be as follows.

   Type    Name                                      Reference
   ------  ----------------------------------------  -------------------
     0      Hello                                    [RFC3973] [RFC4601]
     1      Register                                 [RFC4601]
     2      Register Stop                            [RFC4601]
     3      Join/Prune                               [RFC3973] [RFC4601]
     4      Bootstrap                                [RFC4601]
     5      Assert                                   [RFC3973] [RFC4601]
     6      Graft                                    [RFC3973]
     7      Graft-Ack                                [RFC3973]
     8      Candidate RP Advertisement               [RFC4601]
     9      State Refresh                            [RFC3973]
    10      DF Election                              [RFC5015]
    11-14   Unassigned
    15      Reserved (for extension of type space)   this document

3.2.  Assignment of New Message Types

   Assignment of new message types is done according to the "IETF
   Review" model; see [RFC5226].

4.  Acknowledgements

   Thanks to Toerless Eckert for his suggestion to reserve a type for
   future extension of the message type space.  Also thanks to Mykyta
   Yevstifeyev for reviewing the document and proposing improvements to
   the text.

5.  Informative References

   [IGMPREG]  IANA, "Internet Group Management Protocol (IGMP) Type
              Numbers - per [RFC3228], [BCP57]", <http://www.iana.org/>.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol
              Independent Multicast - Dense Mode (PIM-DM): Protocol
              Specification (Revised)", RFC 3973, January 2005.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)", RFC 5015, October 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

Author's Address

   Stig Venaas
   Cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   EMail: stig@cisco.com

AI ELI5

On this page
PROBLEMPIM version 2 lacked an IANA registry for message types, even though multiple RFCs were defining them.
MECHANISMRFC 6166 creates a registry, populates it with existing message types from RFCs 3973, 4601, and 5015, sets an IETF Review policy for new types, and reserves one type for future extension.
WHY IT MATTERSPIM message types are now centrally documented and managed through a standardized process.

§1Introduction

Protocol Independent Multicast (PIM) is used by routers to manage multicast groups. PIM version 1 used the IGMP protocol and had a registry for message types, but PIM version 2 is independent and needed its own registry. Multiple RFCs like RFC 3973 (PIM Dense Mode), RFC 4601 (PIM Sparse Mode), and RFC 5015 (Bidirectional PIM) defined new message types without a central place to list them all.

Multicast routers need to understand different kinds of messages. Different RFCs added new message types, so they needed a checklist.

§2The Registry

RFC 6166 creates a PIM message type registry in the Protocol Independent Multicast branch at IANA. The message type field is 4 bits, allowing values from 0 to 15. The initial registry includes 10 assigned types: Hello, Register, Register Stop, Join/Prune, Bootstrap, Assert, Graft, Graft-Ack, Candidate RP Advertisement, and State Refresh. Types 11-14 are unassigned, and type 15 is reserved for future extension of the message type space. New types are assigned through IETF Review, meaning they must be defined in a published RFC.

There are 16 numbered slots (0-15) for different message types. Ten are already taken, four are open, and one is saved for if they need to expand in the future.

§3Status

RFC 6166 is a Proposed Standard that was obsoleted by RFC 8736. The PIM message type registry it created is maintained by IANA.

This RFC set up the message type list. A newer RFC (8736) has since taken over the role.

§4References