RFC 6166 PROPOSED STANDARD ROUTING · REGISTRY

PIM Message Registry: A Registry for PIM Message Types

Creates an IANA 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
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

ISO Plain Language

On this page
PROBLEMPIM version 2 message types were specified in several documents without a separate registry to record them.
MECHANISMThe RFC establishes a four-bit message type registry, records the initial values, sets IETF Review for new types, and reserves type 15 for a future extension.
REPLACEDRFC 6166 was obsoleted by RFC 8736.

§1Why PIM Needed a Registry

PIM version 1 used IGMP and had message types listed in an IGMP registry. PIM version 2 is not based on IGMP, while several RFCs define PIM version 2 message types. RFC 6166 creates a separate registry to list those types and provide a process for registering new ones.

PIM version 2 uses its own message types, defined across several RFCs. This RFC gives them a dedicated list.

§3The Registry and Initial Values

The PIM message type field is four bits, with possible values from 0 to 15. The initial registry assigns types 0 through 10 to named messages, leaves 11 through 14 unassigned, and reserves 15 for a future extension of the type space. New message types are assigned through IETF Review.

The four-bit field has values from 0 to 15. The registry records assigned types, leaves some unassigned, and reserves one for future extension.

§2Security Considerations

The RFC says that a well-known place to find valid PIM message types and how they are used may provide a security benefit. Apart from that, the document creates an IANA registry and has no security considerations.

A shared list can help readers identify valid message types. The RFC says it adds no other security considerations.