A Taxonomy on Private Use Fields in Protocols
1307 Kent Oak Dr.
HoustonTexas
77077
US
lonvick.ietf@gmail.com
PEN
namespace
name space
Private name space
Private namespace
Private use space
Private use
Private Enterprise Number
Private Enterprise Code
This document attempts to provide some clarification for the way
that private use fields have been used in protocols developed in the
IETF. It is strictly a taxonomy of what has been published and
offers no advice about how to design or use private use options.
Simply put, communications protocols are standardized ways for
computing entities to convey information. Within each
communications protocol, there must be quantified pieces of
information that will be communicated, and there may be
non-standardized pieces that can be communicated. Since one of
the goals of standards is to provide interoperability, all parties
participating in any communications protocol must be aware of how to
deal with all fields in the protocol.
Some protocols have reserved fields for private and experimental use.
Indeed, having options reserved for testing and experimentation has been
found to be beneficial to the community as has been outlined in
"Assigning Experimental and Testing Numbers Considered Useful".
Fields reserved for private
use cannot provide interoperability unless their use is fully
documented in openly available documents. This specification uses
examples of some protocols to exemplify how some private use
options are used.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
"Key words for use in RFCs to Indicate Requirement Levels".
In this document, the following words are defined to prevent
ambiguity. Some of these words have not been used in the referenced
works but their meanings can be ascertained and applied.
Standard option - a field in a protocol frame that may only use
values that are strictly defined within a specification
Private use option - a field in a protocol frame that is reserved
for private, experimental, testing, or local use only namespaces.
Namespace - the set of possible values a field may contain; its
actual content may be a name, a number, or another kind of value.
Additionally, the terms "Start of Authority" and "Focus of the
Namespace" are defined within their respective contexts and further
discussed below.
The name "Start of Authority" comes from the domain name system
configuration file which describes a "SoA" in
"DOMAIN NAMES - CONCEPTS AND FACILITIES"
and
"DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION".
This includes the person or entity who has ultimate control and decision
making powers over the scope of the domain. Some liberties have been
taken with using this name in this specification, but the intent is to
identify an authoritative source for the namespace.
In many cases throughout this document, RFCs are referenced even though
they are not the most current version of their respective protocol. This
is usually done to reference the first occurrence of a private use option,
or to point out a distinct feature in that specification. When an RFC is
referenced that is not the current version, the reference will be
followed by the RFC number of the current version in curly braces.
Some standards permit private use options in different ways, while others
do not. The "Time Protocol" is an example of a
protocol that only conveys standardized information; there is no
way to use private options and no way to add anything other than what is
specified in the document. In a more open way,
"DOD STANDARD TRANSMISSION CONTROL PROTOCOL"
{} {}
does have "options" but they must be registered through the
IANA before use, which does not leave any
room for optional information supplied by equipment vendors, network
operators, or experimenters. An even more open way may be seen in
"Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)", which
allows for vendor specific options that do not need to be
registered with anyone.
For the case of TCP
{} {},
standard options are
expected; senders may use them and receivers may be configured to
act upon that information, or to ignore it. If an experimenter
wants to add an option, they will have to create a new IETF RFC with
specific details, or obtain approval from the IESG to have the IANA
add to the registry . Similarly, if
equipment vendors Foo and Bar were to have a need for a similar
option within TCP, they would each have to go through the process to
add to the registry. On the other hand, if a properly crafted
multipurpose private use option were to be registered, such as in
the case of multiple vendor instances within
"DHCPv4", then vendors and experimenters
would each be able to use it for their own purposes as long as all
network participants could easily differentiate between the entities
using the option.
"Guidelines for Writing an IANA Considerations Section in RFCs"
{}
describes that values of specific namespaces may either be
registered with the IANA, or not. In most cases, there are well
defined values for namespaces. However, as the document explains,
not all namespaces require centralized administration.
In that document, it seems to be assumed that private use namespaces
will be domain specific and it will be up to the administrators of any
domain to avoid conflicts. The first example given about private use
namespaces refers to
"Dynamic Host Configuration Protocol"
and presumably
"DHCP Options and BOOTP Vendor Extensions".
In this the example states that "site-specific options in DHCP have
significance only within a single site". As noted below this became
a problem that was rectified in a later revision of DHCP.
Later works identified a need to place a scope on private use namespaces.
The second example of private use namespaces in the
IANA guidelines {}
is from
"STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES"
{} which describes X- headers. There was no effort
made to control the namespace and the use of the namespace was
removed when the specification was updated in 2001 in
"Internet Message Format"
{}.
This section summarizes the observed characteristics of some private use
options that have been developed and deployed. Subsequent sections will
explain how these characteristics may have been applied to specific protocols
that are used in the Internet.
There appear to be three quantifiable characteristics of private use
options:
Start of Authority
Focus of the Namespace
Value of the Option
A private use option requires a path to an origin that has the
authority to create and maintain the option. The goal for a globally
unique origin is to disambiguate each focus of a namespace to
allow freedom of expression by the vendors and experimenters using them.
Therefore the referent has most often been seen to be globally unique,
and not dependent upon local interpretation.
Likely, the first private use option was defined in the
"Structure and Identification of Management Information for TCP/IP-based Internets"
which was first used in
"A Simple Network Management Protocol"
{} (SNMP).
The globally unique origin in SNMP is the
International Standards Organization
which is accredited by the United Nations to maintain this
structure.
While SNMP used the entire OBJECT IDENTIFIER with the prefix, other
protocols only used the
Private Enterprise Number (PEN)
as a truncated identification of an origin.
This reduced the length of the
identifier but continued to provide a unique identifier through a
globally managed namespace.
The PEN is sourced by the Internet
Assigned Numbers Authority (IANA). PENs may be viewed as being
similar to domain names in that they are acquired by
individuals, corporations, or other organizations. A notable
difference is that when domain names fall into disuse they may
be acquired and used by entirely different people or
organizations - as per the conditions set forth by the
Internet Corporation for Assigned Names and Numbers,
the source of the domain names. The structure of the PEN
registry does not place any limits on the time that a PEN will
be active or associated with the requester. This is no
different from many other registries maintained by the IANA;
they are just a snapshot at the time of the reservation based on
the information required by the IANA and provided by the
applicant. This eternal association of the PEN, versus the
ephemeral association of domain names, has not been shown to
present any problems to private use options. This may, in fact, be a
feature as this methodology ensures that these namespaces stay unique for
the foreseeable future.
Some additional information on the PEN may be found in
"Enterprise Number for Documentation Use".
An alternative to using numerical indicators is to use textual
strings such as names.
Domain names have similar problems as they may be more ephemeral
than eternal. Unlike PENs that become unserviceable when their
owning organization goes out of business, domain names that fall
into disuse may be acquired and used by entirely different
organization. Similar to the use of PENs there have not been
any problems reported from this.
Uniform Resource Names (URNs) have also been used to convey options.
They seem to provide flexibility for many different needs. URNs were
first defined in
"Uniform Resource Names (URN) Namespace Definition Mechanisms"
{}.
"An IETF URN Sub-namespace for Registered Protocol Parameters"
provides guidance for ways to use URNs as protocol parameters and how to
define a start of authority.
Once the start of authority is established as a globally unique source,
an actual option, or in some cases multiple options, may be specified.
This has been seen to usually be an indicator of what value is expected.
Within the domain established by the start of authority, the focus of
each value has been seen to be unique.
In a very simple example, a private use option may consist of
"SoA"+"focus"="value". The SoA will be unique and will specify the start
of authority. The focus will be unique as long as the start of authority
maintains that uniqueness; e.g., it would be poor form for a private
enterprise to define a focus, then to redefine it at a later time.
This section contains a review of RFCs that allow the use of private
use options.
As was noted, the globally unique origin in SNMP is the
International Standards Organization
which is accredited by the United Nations to maintain this
structure.
The Internet subtree of experimental OBJECT IDENTIFIERs
starts with the prefix: 1.3.6.1.3., and the Internet subtree
of private enterprise OBJECT IDENTIFIERs starts with the
prefix: 1.3.6.1.4.1. This is followed by a
Private Enterprise Number
(PEN) and then the objects defined by that enterprise.
The structure of management information (SMI) is currently defined as the
"Structure of Management Information Version 2 (SMIv2)".
SMI is a well described tree of OBJECT IDENTIFIERs (OIDs).
OIDs have an origin and a path for defined object
identifiers which this document describes as standard
options. It also allows for experimental and vendor
specific object identifiers, which are described as private
use options in this document. The IANA maintains a registry
of these Network Management Parameters
.
After the vendor identifier (the PEN) in the management information
base (MIB), a vendor may create many different trees to identify
objects. This may result in a very large number of OBJECT
IDENTIFIERs, each of which is an identifier, or focus, of a
namespace. Each of these are uniquely identified by the vendor and do
not require registration with any coordinating authority.
The last part of each OBJECT IDENTIFIER is the value
corresponding to the focus, which is known as the varbind.
In a GetRequest the server fills this field with a "0" and
the client responds by replacing the "0" with the actual
value. Since this field is defined by the vendor, it may
actually be a concatenation of values. In a SetRequest
transmitted to the receiver, this is the last field.
Each OBJECT IDENTIFIER contains a globally unique
origin which is ISO, a focus which is the OBJECT IDENTIFIER, and a
value which is the last field in the SetRequest. This is also the
last field in the response to a GetRequest.
Specific codes, known as error-indexes, are used to indicate
when a request cannot be processed because a device does not
understand a request.
"The Remote Authentication Dial In User Service (RADIUS)"
{} specification documented how to use just
the PEN (without the rest of the SMI path to the root) to allow
"vendors" to articulate their own options. In that document, these
are called Vendor-Specific Attributes (VSA).
The updated RADIUS document, ,
gives guidance for using the VSA.
Servers not equipped to interpret the vendor-specific
information sent by a client MUST ignore it (although it
may be reported).
Clients which do not receive desired vendor-specific
information SHOULD make an attempt to operate without
it, although they may do so (and report they are doing
so) in a degraded mode.
The Attribute-Specific field is dependent on the
vendor's definition of that attribute.
It SHOULD be encoded as a sequence of vendor type / vendor length / value fields.
Multiple subattributes MAY be encoded within a single
Vendor-Specific Attribute, although they do not have to
be.
There are many attributes defined in RADIUS
{}
which may be considered to be standard options. Each of
these attributes is specified within a "type length value"
(TLC) container. For this protocol, the attribute "type" is
a specific numerical value which differentiates it from
other attributes.
One example of a RADIUS standard option is Type 26, which denotes the
Vendor Specified Attribute. It is "available to allow vendors to
support their own extended Attributes not suitable for general
usage". The PEN of the "vendor" starts the "value" which should then include a
subsequent nested TLV so the vendor may define and enumerate their
own options within that field.
As noted above, the globally unique origin for
"RADIUS" is the PEN. The
remainder of the Attribute field after the PEN is
deliberately undefined in the specification. It is however
suggested that the field contain embedded TLVs. This is
again very practical. Each vendor may then have conflicting
"types" (e.g. "1") which would be disambiguated by the
origin. For example [PEN="N", type="1"] is different from
[PEN="M", type="1"].
The values for each type are bounded by the length of the
attribute. The protocols exemplified here tend to be
machine-to-machine readable therefore it is likely
that the values will not be human readable. In some cases,
it is feasible that a value has no length. In that case,
the transmission of the type alone, has been seen to be a signal of
some sort to the receiver.
The original specification of
{} provided
guidance that invalid packets were to be silently discarded. That
was augmented in to say that RADIUS clients
and servers may ignore Attributes with an unknown type.
"Mobile IP Vendor Specific Extensions"
defines two extensions that can be used for making
organization specific extensions by vendors/organizations
for their own specific purposes for Mobile IP
{}.
In that specification, two TLVs have been defined to
contain private use options. These are collectively called
Vendor/Organization Specific Extensions (VSE).
When the Critical Vendor/Organization Specific Extension
(CVSE) is encountered but not recognized, the message
containing the extension MUST be silently discarded.
When a Normal Vendor/Organization Specific Extension
(NVSE) is encountered but not recognized, the extension
SHOULD be ignored, but the rest of the Extensions and
message data MUST still be processed.
Having two VSEs of this nature for private use options is
consistent with the original Mobile IP specification
{} which states:
When an Extension numbered in either of these sets
within the range 0 through 127 is encountered but not
recognized, the message containing that Extension MUST
be silently discarded. When an Extension numbered in
the range 128 through 255 is encountered which is not
recognized, that particular Extension is ignored, but
the rest of the Extensions and message data MUST still
be processed.
The structure of the origin, type, and value of the CVSEs
and NVSEs for "Mobile IP" has been seen
to be used in a manner very similar to that of RADIUS. The PEN is
the origin and types and values may be stacked within the
field. The values are constrained by the length of the types or
subtypes.
The introduction to
"Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)"
states:
The DHCP protocol for IPv4, ,
defines options that allow a client to indicate its
vendor type (option 60), and the DHCP client and server
to exchange vendor-specific information (option 43)
. Although there is no
prohibition against passing multiple copies of these
options in a single packet, doing so would introduce
ambiguity of interpretation, particularly if conveying
vendor-specific information for multiple vendors.
This appears to indicate that
"Dynamic Host Configuration Protocol"
specified that there was one instance of the vendor type,
and the receiver used that namespace to set the scope for
the fields in the vendor-specific information option. This
version of DHCP did not allow for multiple origins; only a
single origin was permitted and the types were to be defined
subsequent to that. Evidently this was found to be
unworkable when different vendors needed to expand private
use options in the protocol.
This situation was resolved with the publication of
"Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)"
which cautions:
The Dynamic Host Configuration Protocol (DHCP) options
for Vendor Class and Vendor-Specific Information can be
limiting or ambiguous when a DHCP client represents
multiple vendors.
That specification () then used the
PEN to define a unique namespace
for private use options in this protocol. Similar to other
protocols of this era, TLV containers were used.
When this protocol was updated to conform to the
requirements of IPv6, the PEN was again used as the way to
identify the origin of the private use option.
provides guidance on actions to take if
servers and clients do not comprehend a request or a response.
Servers not equipped to interpret the vendor-specific information
sent by a client MUST ignore it. Clients that do not receive desired
vendor-specific information SHOULD make an attempt to operate without
it.
"The Syslog Protocol" also uses
the PEN to uniquely qualify the namespace for a private use
option. Standard options do not contain the "@" character.
Private use options must have the PEN following the "@"
character. This allows a vendor or experimenter to have
overlapping namespaces which the PEN will then uniquely
identify. For example the standard option of tzKnown may
only have associated values of "0" and "1". However
tzKnown@32473 may have any value assigned to it by the owner
of enterprise number 32473.
Syslog transport receivers are supposed to accept all
correctly formatted Syslog messages. Unlike RADIUS, the
receiving Syslog application does not have to have immediate
knowledge of all variable options to continue operations.
If a private use option is not immediately known to the
receiving application, it may still store the message and an
Operator or Administrator may look it up at a later time if
they are interested.
The Syslog protocol uses the
PEN as the origin and allows for the focus of the private
use option to be fully defined by the vendor within the
structured data. Specifically, a vendor may define a "type"
of private use option by concatenating it with the PEN by
using the @ character. Within the bounds of the structured
data, multiple elements may be used that have identifiers
and values.
"The Secure Shell (SSH) Protocol Architecture"
uses character strings rather than PENs. Similar to Syslog,
but actually predating it, standard options must not have
the "@" character in them. Private use options will have an
origin identifier preceding an "@" character followed by a
namespace field. For example, in
"The Secure Shell (SSH) Connection Protocol"
SSH channels may be opened by specifying a channel type when
sending the SSH_MSG_CHANNEL_OPEN message. Standard options
for the channel type include "session" and "x11". A private
use option for a channel type could be
"example_session@example.com".
The rational for choosing the manner of providing a format for
private use options is given in Section 4.2 of
.
We have chosen to identify algorithms, methods, formats, and
extension protocols with textual names that are of a specific format.
DNS names are used to create local namespaces where experimental or
classified extensions can be defined without fear of conflicts with
other implementations.
The character strings are domain names as defined in
and . This
is specified in
"The Secure Shell (SSH) Protocol Architecture".
Generally, the guidance given is that if a private use
option of this nature is not understood it is to convey an
error code to its peer.
In the SSH protocol, the
origin is a domain name and the focus of the option is
dependent upon context. For example,
ourcipher-cbc@example.com can only be used when negotiating
ciphers, while example_session@example.com can only be used
when negotiating channel types, per the examples in
.
One example of a protocol utilizing URNs is
"Network Configuration Protocol (NETCONF)".
NETCONF may utilize
"YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)"
as a means to describe and convey options.
"YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)"
and
"Network Configuration Protocol
(NETCONF)" use URIs to indicate private use namespaces.
Section 8.3 of YANG describes
the parsing of the YANG payload. It contains a good deal of
information about how to process elements or values that are
not recognized.
Similarly, NETCONF contains
much information about processing requests that cannot be
completed because elements or values are not recognized.
Both YANG and
NETCONF use URIs to enumerate
private use options of a device. The use of this comes from
XPATH.
In both of these, the start of authority is the domain name
in the URI and the origin is the full URI path. Many
private use options may be described within YANG. From
that, each private use option may be populated in NETCONF.
The
"Extensible Provisioning Protocol (EPP)"
is another example of a protocol that utilizes URN namespaces. From
the Protocol Description section 2:
EPP uses XML namespaces to provide an extensible object management
framework and to identify schemas required for XML instance parsing
and validation. These namespaces and schema definitions are used to
identify both the base protocol schema and the schemas for managed
objects.
The specification provides clear guidance and an example on how to
extend the base protocol and how to map new objects through the use
of separate documents. However, commands and responses may be
extended through the use of an <extension> element. In this protocol,
and the extensions, the start of authority is the domain name in the
URI and the focus is the full URI path.
Guidance has been provided about incomplete understanding. First, a
section is provided on responses for received messages that are
not understandable, are beyond boundaries, or are not in compliance
with policy. Additionally, guidance is given about incomplete
understanding of a response:
Command success or failure MUST NOT be assumed if no response is
returned or if a returned response is malformed. Protocol
idempotency ensures the safety of retrying a command in cases of
response-delivery failure.
The associated RFCs of
"Extensible Provisioning Protocol (EPP) Domain Name Mapping"
and
"Extensible Provisioning Protocol (EPP) Host Mapping"
provide a mechanism to temporally bind options.
Private use options are a way to allow vendors, network operators,
and experimenters to convey dynamic information without going
through any process to register each variable. However, there is no
one size fits all. The use of a very specific and fixed
format works for RADIUS which requires speed in
processing. On the other hand, the open nature of the private use
options in Syslog are appropriate for that protocol where event
messages need not be fully parsed at the time of reception.
As with all good things, the use of private use options comes with a cost.
Adding any extra fields to a protocol will require additional processing for
both the sender and the receiver. Also, larger packets will take up more
bandwidth in transmission. In another aspect, the code needed to deal with
private use options may be considered wasteful if it is not used.
There appear to be five quantifiable features that have been documented in
using a private use option.
One feature is to have a definable way for the community to
ascertain the nature of all private use options. For example,
several vendors have published their RADIUS VSAs on web pages,
which are easy to find. From that, anyone creating a new RADIUS
server would have access to, and be able to incorporate the
information available.
Instructions have frequently been provided on how to deal with incomplete
understanding; where private use options are not understood by a
receiver. Within the example protocol specifications given in this
document, some behavior has usually been established about what to do if
the receiver does not understand a namespace. Some protocols have defined
that a receiver will silently discard packets that contain private use
options they do not understand. Other protocols have defined that they
will only discard the private use option rather than the entire packet.
On the other hand some other protocols have no need for the receiver to
have any understanding of any private use options when it receives any.
The values of private use options have frequently followed
the same guidance given for standard options in their respective
specifications. In most of the examples given, the value of each private
use option has been well defined and bounded. Most have been defined to
be extensible so as to accomodate future requirements.
Private use options may be extensible in a clearly designed
way. RADIUS suggests that the string containing the option be
another TLV. This allows a vendor to define multiple private
use options within their own namespace field. These are known as
subattributes.
In some cases, a unique option may only be used once within the context
of an exchange. This may define a value of an option once and will not
change that value during the remainder of the session. RADIUS and DHCP
seem to either state this or strongly imply it. However, while it is not
explicitly discussed, it appears that nothing prevents this within
Syslog, and it seems to be acceptable behavior to resend unique options
multiple times within EPP.
Clear documentation has been seen to achieve
uniformity and interoperability in these features. Obviously
implementers will need to adhere closely to these standards for
complete interoperability.
This document is not an encouragement or recommendation to define
private use fields in IETF protocols. Rather, since private use
options are being used by the community, this document is an attempt to
document the ways in which they have been used.
However,
"Design Considerations for Protocol Extensions"
is intended to provide guidance on designing protocol extensions. It has
several examples and pointers to other material that will aid in the
development of protocol extensions.
"Procedures for Protocol Extensions and Variations"
is a companion document to and provides the
procedures for review and standardization for extensions to be added to
protocols.
Finally, the usage of any private use values on the wire before any
namespace is properly reserved with the IANA is entirely
inadvisable.
This section will be removed prior to publication.
This is version -12. I finally got some time to work on this.
A recommendation has been made to update RFC5226 with ID
draft-leiba-cotton-iana-5225bis. If that becomes an RFC while this document
is pending, I'll do that.
This document reviews ways that options are being used in various
protocols. As such, there are no security considerations inherent
in this document.
Readers and implementers should be aware of the context of
implementing options in protocols they are using or that are being
developed.
This document does not propose a standard and does not require the
IANA to do anything.
The idea for documenting this came from questions asked in the
SIP-CLF Working Group and the author is grateful for the discussion
around this topic.
The following people have contributed to this document. Listing
their names here does not mean that they agree with or endorse the
document, but that they have contributed to its substance.
David Harrington, Dan Romascanu, Bert Wijnen, Ralph Droms, Juergen
Schoenwalder, Nevil Brownlee, Klaas Wierenga, and Brian Carpenter.
IANA Transmission Control Protocol (TCP) Parameters, TCP Option Kind Numbers
Internet Assigned Numbers Authority
Network Management Parameters
Internet Assigned Numbers Authority
IANA PRIVATE ENTERPRISE NUMBERS
Internet Assigned Numbers Authority
International Standards Organization
International Standards Organization
Internet Corporation for Assigned Names and Numbers
Internet Corporation for Assigned Names and Numbers