PEN Registration: Registration Procedures for Private Enterprise Numbers (PENs)
How to get and manage a Private Enterprise Number for your organization.
Baber, A. and P. Hoffman, "Registration Procedures for Private Enterprise Numbers (PENs)", RFC 9371, DOI 10.17487/RFC9371, March 2023, <https://www.rfc-editor.org/info/rfc9371>.
@misc{rfc9371,
series = {Request for Comments},
number = 9371,
howpublished = {RFC 9371},
publisher = {RFC Editor},
doi = {10.17487/RFC9371},
url = {https://www.rfc-editor.org/info/rfc9371},
author = {A. Baber and P. Hoffman},
title = {{Registration Procedures for Private Enterprise Numbers (PENs)}},
pagetotal = 6,
year = 2023,
month = mar,
} RFC text
Contents
Internet Engineering Task Force (IETF) A. Baber
Request for Comments: 9371 IANA
Category: Informational P. Hoffman
ISSN: 2070-1721 ICANN
March 2023
Registration Procedures for Private Enterprise Numbers (PENs)
Abstract
This document describes how Private Enterprise Numbers (PENs) are
registered by IANA. It shows how to request a new PEN and how to
modify a current PEN. It also gives a brief overview of PEN uses.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9371.
Copyright Notice
Copyright (c) 2023 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
(https://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 Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
1.1. Uses of PENs
2. PEN Assignment
2.1. Requesting a PEN Assignment
2.2. Modifying an Existing Record
2.3. Deleting a PEN Record
3. PEN Registry Specifics
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Authors' Addresses
1. Introduction
Private Enterprise Numbers (PENs) are identifiers that can be used
anywhere that an ASN.1 object identifier (OID) [ASN1] can be used.
Originally, PENs were developed so that organizations that needed to
identify themselves in Simple Network Management Protocol (SNMP)
[RFC3411] Management Information Base (MIB) configurations could do
so easily. PENs are also useful in any application or configuration
language that needs OIDs to identify organizations.
The IANA Functions Operator, referred to in this document as "IANA",
manages and maintains the PEN registry in consultation with the IESG.
PENs are issued from an OID prefix that was assigned to IANA. That
OID prefix is 1.3.6.1.4.1. Using the (now archaic) notation of
ownership names in the OID tree, that corresponds to:
1 3 6 1 4 1
iso.org.dod.internet.private.enterprise
A PEN is an OID that begins with the PEN prefix. Thus, the OID
1.3.6.1.4.1.32473 is a PEN.
1.1. Uses of PENs
Once a PEN has been assigned to an organization, individual, or other
entity, that assignee can use the PEN by itself (possibly to
represent the assignee) or as the root of other OIDs associated with
the assignee. For example, if an assignee is assigned the PEN
1.3.6.1.4.1.32473, it might use 1.3.6.1.4.1.32473.7 to identify a
protocol extension and use 1.3.6.1.4.1.32473.12.3 to identify a set
of algorithms that it supports in a protocol.
Neither IANA nor the IETF can control how an assignee uses its PEN.
In fact, no one can exert such control: that is the meaning of
"private" in "private enterprise number". Similarly, no one can
prevent an assignee that is not the registered owner of a PEN from
using that PEN, or any PEN, however they want.
A very common use of PENs is to give unique identifiers in IETF
protocols. SNMP MIB configuration files use PENs for identifying the
origin of values. Protocols that use PENs as identifiers of
extension mechanisms include RADIUS [RFC2865], Diameter [RFC6733],
Syslog [RFC5424], RSVP [RFC5284], and vCard [RFC6350].
2. PEN Assignment
PENs are assigned by IANA. The registry is located at
<https://www.iana.org/assignments/enterprise-numbers>, and requests
for new assignments or the modification of existing assignments can
also be submitted at that URL.
IANA maintains the PEN registry in accordance with the "First Come
First Served" registration policy described in [RFC8126]. Values are
assigned sequentially.
2.1. Requesting a PEN Assignment
Requests for assignment must provide the name of the assignee, the
name of a public contact who can respond to questions about the
assignment, and contact information that can be used to verify change
requests. The contact's name and email address will be included in
the public registry.
A prospective assignee may request multiple PENs, but obtaining one
PEN and making internal sub-assignments is typically more
appropriate. (Sub-assignments should not be reported to IANA.)
IANA may refuse to process abusive requests.
2.2. Modifying an Existing Record
Any of the information associated with a registered value can be
modified, including the name of the assignee.
Modification requests require authorization by a representative of
the assignee. Authorization will be validated either with
information kept on file with IANA or with other identifying
documentation, if necessary.
2.3. Deleting a PEN Record
Although such requests are rare, registrations can be deleted. When
a registration is deleted, all identifying information is removed
from the registry, and the value is marked as "returned." Returned
values will not be made available for reassignment until all other
unassigned values have been exhausted; as can be seen in Section 3,
the unassigned values are unlikely to ever run out.
3. PEN Registry Specifics
The range for values after the PEN prefix is 0 to 2**32-1. The
values 0 and 4294967295 (2**32-1) are reserved. Note that while the
original PEN definition had no upper bound for the value after the
PEN prefix, there is now an upper bound due to some IETF protocols
limiting the size of that value. For example, Diameter [RFC6733]
limits the value to 2**32-1.
There is a PEN number, 32473, reserved for use as an example in
documentation. This reservation is described in [RFC5612].
Values in the registry that have unclear ownership are marked
"Reserved". These values will not be reassigned to a new company or
individual without consulting the IESG.
4. IANA Considerations
Per this document, IANA has made the following changes to the PEN
registry:
* Values 2187, 2188, 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144,
5201, 5683, 5777, 6260, 6619, 14827, 16739, 26975, and the range
from 11670 to 11769, which had been missing from the registry,
have been listed as "Reserved." As described in [RFC8126],
reserved values can be released by the IESG.
* This document has been listed in the registry's "Reference" field.
* "First Come First Served" has been listed as its registration
procedure.
5. Security Considerations
Registering PENs does not introduce any significant security
considerations.
There is no cryptographic binding of a registrant in the PEN registry
and the PEN(s) assigned to them. Thus, the entries in the PEN
registry cannot be used to validate the ownership of a PEN in use.
For example, if the PEN 1.3.6.1.4.1.32473 is seen in a protocol as
indicating the owner of some data, there is no way to securely
correlate that use with the name and assignee of the owner listed in
the PEN registry.
6. References
6.1. Normative References
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
6.2. Informative References
[ASN1] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, February 2021,
<https://www.itu.int/rec/T-REC-X.690/en>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
DOI 10.17487/RFC3411, December 2002,
<https://www.rfc-editor.org/info/rfc3411>.
[RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP",
RFC 5284, DOI 10.17487/RFC5284, August 2008,
<https://www.rfc-editor.org/info/rfc5284>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424,
DOI 10.17487/RFC5424, March 2009,
<https://www.rfc-editor.org/info/rfc5424>.
[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for
Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August
2009, <https://www.rfc-editor.org/info/rfc5612>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>.
Acknowledgements
An earlier draft version of this document was authored by Pearl Liang
and Alexey Melnikov. Additional significant contributions have come
from Dan Romascanu, Bert Wijnen, David Conrad, Michelle Cotton, and
Benoit Claise.
Authors' Addresses
Amanda Baber
Internet Assigned Numbers Authority
PTI/ICANN
12025 Waterfront Drive
Los Angeles, 90094
United States of America
Email: amanda.baber@iana.org
Paul Hoffman
ICANN
12025 Waterfront Drive
Los Angeles, 90094
United States of America
Email: paul.hoffman@icann.org
AI ELI5
On this page
§1What are PENs
Private Enterprise Numbers (PENs) are identifiers that can be used wherever an ASN.1 object identifier (OID) can be used. Originally developed so that organizations could identify themselves in Simple Network Management Protocol (SNMP) Management Information Base (MIB) configurations, PENs have become useful in any application or configuration language that needs OIDs to identify organizations.
The IANA Functions Operator manages the PEN registry. All PENs start with the OID prefix 1.3.6.1.4.1 (representing iso.org.dod.internet.private.enterprise). A complete PEN looks like 1.3.6.1.4.1.32473, and the organization can then create sub-OIDs such as 1.3.6.1.4.1.32473.7 for their own purposes.
A PEN is like a company code number that identifies the organization in computer systems. It starts with a standard prefix that everyone shares, then adds a unique number for each company.
§2Uses of PENs
Once assigned a PEN, an organization can use it by itself to represent the organization, or as the root for creating other OIDs associated with the organization. For example, an organization might use 1.3.6.1.4.1.32473.7 to identify a proprietary protocol extension and 1.3.6.1.4.1.32473.12.3 to identify a set of algorithms it supports.
PENs are frequently used in IETF protocols to provide unique identifiers. SNMP MIB configuration files use PENs to identify the origin of values. Protocols that use PENs as identifiers for extension mechanisms include RADIUS, Diameter, Syslog, RSVP, and vCard. Critically, IANA and the IETF cannot control how an assignee uses its PEN—the whole point of "private" in the name is that the assignee has full freedom.
Once a company has a PEN, it can use the number itself, or use sub-numbers under it. For example, a networking protocol might let a company announce its own extensions using its PEN, which tells everyone that the extensions come from that company.
§3Requesting and Managing PENs
PENs are assigned by IANA using the "First Come First Served" registration policy, with values assigned sequentially. Organizations request a PEN by providing the name of the assignee, the name of a public contact who can answer questions about the assignment, and contact information for verifying change requests. The contact's name and email will be listed in the public registry.
An organization may request multiple PENs, but obtaining one PEN and making internal sub-assignments is typically more appropriate. IANA may refuse to process abusive requests. Organizations can modify any information in their registration, including the assignee name, by providing authorization from a representative of the assignee. When a PEN is deleted (a rare occurrence), all identifying information is removed and the value is marked as "returned." Returned values will not be reassigned until all unassigned values have been exhausted.
To get a PEN, you tell IANA who you are and who to contact about it. IANA assigns numbers in order. If you need to change your information later, you can ask, and IANA will check that you are the owner. If you want to return a PEN, IANA will mark it as used, but won't give it to someone else for a long time.
§4Registry Constraints and Special Values
The range of PEN values after the prefix is 0 to 2^32-1 (4,294,967,295). The values 0 and 4,294,967,295 are reserved and cannot be assigned. While the original PEN definition had no upper bound, an upper bound now exists because some IETF protocols (such as Diameter) limit the PEN value to 2^32-1.
The PEN number 32473 is reserved for use as an example in documentation, as specified in RFC 5612. Values in the registry that have unclear ownership are marked "Reserved." These values will not be reassigned to a new company or individual without consulting the IESG.
PENs can be any number from 1 to about 4 billion. Some special numbers are kept for examples or for cases where no one remembers who should own them.
§5Security Considerations
Registering PENs does not introduce significant security considerations for the registration process itself. However, there is an important limitation: there is no cryptographic binding between a registrant in the PEN registry and the PEN(s) assigned to them. Therefore, entries in the PEN registry cannot be used to validate ownership of a PEN in use. For example, if the PEN 1.3.6.1.4.1.32473 appears in a protocol message indicating the owner of some data, there is no way to securely correlate that use with the name and contact listed in the registry. Users who need to verify ownership of a PEN must rely on other out-of-band mechanisms.
The registry tells you what company owns each number, but it does not prove ownership if someone uses the number. If you see a number in a message, you cannot be sure just from the registry that the message really came from the owner.