A Registry for PIM Message Types
draft-ietf-pim-registry-02.txt

Abstract

This document provides instructions to IANA for the creation of a registry for PIM message types. It specifies 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on July 14, 2011.

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.  Security Considerations
3.  IANA Considerations
    3.1.  Initial registry
    3.2.  Assignment of new message types
4.  Acknowledgements
5.  References
    5.1.  Normative References
    5.2.  Informative References
§  Author's Address

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] (Deering, S., “Host extensions for IP multicasting,” August 1989.) and there is an IGMP registry [IGMPREG] (IANA, “IGMP Type Numbers,” June 2005.) 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] (Adams, A., Nicholas, J., and W. Siadak, “Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised),” January 2005.), PIM Sparse Mode [RFC4601] (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.) and Bidirectional PIM [RFC5015] (Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, “Bidirectional Protocol Independent Multicast (BIDIR-PIM),” October 2007.).

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

This document requests IANA to create a PIM message type registry. This should be placed in the "Protocol Independent Multicast (PIM)" branch of the tree. Each entry in the registry consists of message type, message name and references to the documents defining the type.

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]
 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] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.).

4.  Acknowledgements

Thanks to Toerless Eckert for his suggestion to reserve a type for future message type space extension.

5.  References

5.1. Normative References

5.2. Informative References

Author's Address