One document matched: draft-lonvick-private-tax-08.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" ipr="pre5378Trust200902" docName="draft-lonvick-private-tax-08.txt">
<front>
<title abbrev='Private Use Fields'>
A Taxonomy on Private Use Fields in Protocols
</title>
<author initials="C.M." surname="Lonvick"
fullname="Chris Lonvick">
<address>
<postal>
<street>538 Brooks Ave.</street>
<city>San Jose</city><region>California</region>
<code>95125</code>
<country>US</country>
</postal>
<email>lonvick.ietf@gmail.com</email>
</address>
</author>
<date month="June" year="2014" />
<keyword>PEN</keyword>
<keyword>Private name space</keyword>
<keyword>Private use space</keyword>
<keyword>Private use</keyword>
<keyword>Private Enterprise Number</keyword>
<keyword>Private Enterprise Code</keyword>
<abstract>
<t>
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 a minimal amount of advice about how to design or use private
use options.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Simply put, communications protocols are standardized ways for
computing entities to convey information. Within each
communications protocol, there must be standardized 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. Fields reserved for private
use cannot provide interoperability unless their use is fully
documented in openly available documents. This section uses
examples of some well known protocols to demonstrate the differences
between protocols that use private use options, and those that
don't.
</t><t>
Existing standards permit private use options in different ways.
The
<xref target="RFC0868">Time Protocol</xref> is an example of a
protocol that only conveys standardized information. There is no
way to add anything other than what is specified in the document.
On the other hand,
<xref target="RFC0761">DOD STANDARD TRANSMISSION CONTROL PROTOCOL</xref>
does have "options" but they must be registered through the
IANA <xref target="IANAtcp" /> before use, which does not leave any
room for optional information supplied by equipment vendors, network
operators, or experimenters. Finally,
<xref target="RFC3925">Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)</xref>
does allow for vendor specific options that do not need to be
registered with anyone.
</t><t>
If a network operator wanted to add specific information to the
<xref target="RFC0868">Time Protocol</xref>, they could modify the
code of all senders and receivers and run this within their own
domain without any problems. However, if an equipment vendor wanted
to include information specific to their equipment, they would have
to ensure that all senders and receivers within all network domains
would either accept the change in the protocol, or would not have
problems with it. As a final case, if several equipment vendors
desired to add equipment-specific information to this protocol, they
would have to take great care that only their own receivers would
accept information from their own transmitters. An extension to
that would be that if one equipment vendor would like to transmit or
receive the same information that another vendor is using.
</t><t>
For the case of TCP <xref target="RFC0761" />, 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 <xref target="IANAtcp" />. 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
<xref target="RFC3925">DHCPv4</xref>, 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.
</t><t>
This document explores the various ways that protocols have allowed
optional information to be included using fields designated as
"private use". It uses examples of some well known protocols. In
well developed protocols, private use options may be useful in
avoiding allocation conflicts, and in dynamically extending a
feature. As with all good things, this will come 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, a receiver will have to reserve buffers for an expected
field in an inbound packet. Since one way of implementing private
use options is to only enable the field if it is needed, then the
allocation of buffers could be considered wasteful if it is actually
not used.
</t>
</section>
<section anchor="history" title="Origins of the Private Use Name Space">
<t>
<xref target="RFC2434">Guidelines for Writing an IANA Considerations Section in RFCs</xref>
describes that values of specific name spaces may either be
registered with the IANA, or not. In most cases, there are well
defined values for name spaces. However, as the document explains,
not all name spaces require centralized administration.
</t><t>
In that document, it seems to be assumed that private use name
spaces 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 name spaces refers to
<xref target="RFC2131">Dynamic Host Configuration Protocol</xref>
and presumably
<xref target="RFC2132">DHCP Options and BOOTP Vendor Extensions</xref>.
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.
</t><t>
Later works identified a need to place a scope on private use name
spaces. The second example of private use name spaces in the
<xref target="RFC2434">IANA guidelines</xref> is from
<xref target="RFC0822">STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES</xref>
which describes X- headers. Again, there is no effort made to
control the name space. It appears however that the users of X-
headers have self-organized; most consistently use features that are
universally useful and many have incorporated identifiers for useful
features that may overlap.
</t>
</section>
<section anchor="words" title="Nomenclature">
<t>
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.
<list style="symbols"><t>
Communications protocol - a formal description of digital message
formats and the rules for exchanging those messages in or between
computing systems and in telecommunications <xref target="wpProt" />
<list style="empty"><t>
Example:
<xref target="RFC0959">The File Transfer Protocol</xref>
is an example of a communications protocol. It has well defined
fields and standard options.
<xref target="RFC5424">The Syslog Protocol</xref>
is another example of a communications protocol. It has well
defined fields, standard options, and it also has standard and
private use options. (See <xref target="syslog" />.)
</t></list>
</t><t>
Protocol frame - a defined container of fields used to convey
information in a communications protocol
<list style="empty"><t>
Example: An Internet Protocol packet <xref target="RFC0791" />
is considered to be a protocol frame. In the case of
<xref target="RFC0959">The File Transfer Protocol</xref>, an FTP
message from the client to the server within the
<xref target="RFC0791">Internet Protocol</xref>
containing an FTP command is a protocol frame. In the case of
<xref target="RFC5424">The Syslog Protocol</xref>, a message
from the client to the server within the
<xref target="RFC0791">Internet Protocol</xref> containing a
syslog message is also a protocol frame.
</t></list>
</t><t>
Field - any defined container within a communications protocol frame
<list style="empty"><t>
Example: In the case of
<xref target="RFC0959">The File Transfer Protocol</xref>, a
command will be contained within a field. In the case of
<xref target="RFC5424">The Syslog Protocol</xref>, the HOSTNAME
is a field.
</t></list>
</t><t>
Standard option - a field in a protocol frame that may only use
values that are strictly defined within a specification
<list style="empty"><t>
Example: In the case of
<xref target="RFC0959">The File Transfer Protocol</xref>, an FTP
command, such as CDUP or QUIT, is a standard option. The reason
that a command is a standard option is that only the values
listed by the IANA in the registry <xref target="IANAftp" /> may
be used. The standard options are not limited to the values
defined in the original RFC, but also include any additions to
the registry. In the case of
<xref target="RFC5424">The Syslog Protocol</xref>, an SD-ID may
be a standard option. The example given in Section 7.1.4 of
<xref target="RFC5424" /> of
<figure><artwork><![CDATA[
[timeQuality tzKnown="0" isSynced="0"]
]]></artwork></figure>
is a standard option because all of the fields are listed in the
document and in the IANA registry <xref target="IANAslg" />.
</t></list>
</t><t>
Private use option - a field in a protocol frame that is reserved
for private or local use only name spaces
<list style="empty"><t>
Example: In the case of The Syslog Protocol, an SD-ID may be a
private use option. Example 3 given in Section 6.5 contains a
private use option.
<figure><artwork><![CDATA[
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com
evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
"Application" eventID="1011"] BOMAn application
event log entry...
]]></artwork></figure>
Specifically, the SD-ID starting with "[exampleSDID@32473 ..."
is not a specifically defined option in the RFC, nor is it
registered in the IANA registry <xref target="IANAslg" />. It
is a way for an equipment vendor to insert their specific
information without having to register anything. In this case
if the receiver knows the format of that SD-ID then it can
immediately interpret its meaning. However, if it does not know
how to interpret that SD-ID, it can still log the message and an
Operator or Administrator can look up its meaning at a later
time.
</t></list>
</t><t>
Name space - the set of possible values a field may contain; its
actual content may be a name, a number or another kind of value
<list style="empty"><t>
Example: In the same Example 3 from Section 6.5 of
<xref target="RFC5424">The Syslog Protocol</xref>,
"exampleSDID@32473" provides the name space so the context of
the rest of the SD-ID may be interpreted. Specifically, the
Private Enterprise Number <xref target="IANApen" /> (PEN) is
used to associate the option with a private enterprise, and the
text before the "@" identifies the option defined within that
private enterprise.
</t></list>
</t></list></t>
<t>
Additionally, the terms "Source of Authority" and "Focus of the
Namespace" are defined and further discussed below.
</t>
</section>
<section anchor="means" title="Characteristics of Useful Private Use Options">
<t>
Private use options can be separated into discreet pieces of
information. The interpretation of each piece of information places
its context. The interpretation of the entirety of these pieces of
information will uniquely describe the context of the information
and the value associated with it. This must provide a single and
unique interpretation of the information to each receiver.
</t><t>
This section summarizes the observed characteristics of private use
options that are successful and deployed. Following sections will
explain how these characteristics apply to specific protocols that
are commonly used in the Internet.
</t><t>
There seem to be three characteristics of successful private use
options:
<list>
<t>A Source of Authority
</t><t>A Focus of the Name Space
</t><t>A Value of the Option
</t>
</list>
</t><t>
As an example, in SNMP the combination of the Source of
Authority and the Focus of the Name Space (Focus) represent the
OID. The combination of the Source of Authority, the Focus, and the
Value of the Option (Value) constitute the VarBind.
</t>
<section anchor="means1" title="Source of Authority">
<t>
A private use option requires a path to an origin that has the
authority to create and maintain the option. As shown above,
this referent should be unique, and not be dependent upon local
interpretation.
</t><t>
The name "Source of Authority" comes from the domain name system
configuration file which enumerates a "SoA" as 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 but the intent is to identify an authoritative
source for the namespace.
</t><t>
The <xref target="pen">PEN</xref> is sourced by the Internet
Assigned Numbers Authority (IANA). These 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 required by the
<xref target="ICANN">Internet Corporation for Assigned Names and Numbers</xref>,
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. This may, in fact, be a feature as this
methodology ensures that these namespaces stay unique for the
foreseeable future.
</t><t>
Domain names have similar problems as they can 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
organizations. Similar to the use of PENs there have not been
any problems reported from this.
</t><t>
It is vital to note that the usage of the option within the
private space is the full responsibility of the private entity.
In the example of the PEN, each entity registering a PEN must
fully quantify the parameters of the use of the option within
their purview.
</t>
</section>
<section anchor="means2" title="Focus of the Name Space">
<t>
Once the source of authority is established, an actual option,
or multiple options, must be specified. This is usually an
indicator of what value is expected. Within the domain
established by the source of authority, the focus of each value
must be unique. In a very simple example, a private use option
may consist of "PEN"@"focus"="value". The PEN will be unique
and will specify the source of authority. The focus will be
unique as long as the source 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.
</t><t>
In some cases, multiple focuses and values need to be
transmitted. When the PEN has been used, this has most often
been achieved by nesting "type length value" (tlv's) within the
field. Each type is then a focus for the private use option.
More recently URIs have been used to point to a source of
authority. This allows an organization to organize an abundance
of information about their name spaces.
</t>
</section>
</section>
<section anchor="ways" title="Examples of Successful Private Use Options">
<t>
This section contains a review of RFCs that allow the use of private
use options. There seem to be three ways to address the name space:
via a global origin, via a truncated numerical origin, and via a
name space based upon a domain name.
</t>
<section anchor="pen" title="Private Enterprise Number">
<t>
Rather than using the entire SMI, protocol engineers started
using just the Private Enterprise Number
<xref target="IANApen" />. This reduces the length of the
identifier but continues to provide an identifier through a
globally unique name space. This section provides examples of
how the PEN has been used to provide private use options.
</t>
<section anchor="smi" title="SNMP">
<t>
Likely, the first private use option was defined in the
<xref target="RFC1155">Structure and Identification of Management Information for TCP/IP-based Internets</xref>
which was first used in
<xref target="RFC1067">A Simple Network Management Protocol</xref>
(SNMP). The structure of management information (SMI) has
been updated and is currently defined as the
<xref target="RFC2578">Structure of Management Information Version 2 (SMIv2)</xref>.
</t><t>
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
<xref target="IANAsmi" />.
</t><t>
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
<xref target="IANApen">Private Enterprise Number</xref>
(PEN) and then the objects defined by that enterprise.
</t>
<t>
The globally unique origin in <xref target="smi">SNMP</xref>
is the
<xref target="ISO">International Standards Organization</xref>
which is accredited by the United Nations to maintain this
structure. However, the name space resolves to the
<xref target="pen">PEN</xref>.
</t><t>
After the vendor identifier (the PEN) in the management
information base (MIB), a vendor can create many different
trees to identify objects. This may result in a very large
number of OBJECT IDENTIFIERs; each of which is an identifier
of the name space described in this document. Each of these
are uniquely identified by the vendor and do not require
registration with any coordinating authority.
</t><t>
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.
</t><t>
In this, each OBJECT IDENTIFIER contains a globally unique
origin which is ISO, a focus which is the OBJECT IDENTIFIER
down to the last field, and a value which is the last field
in the SetRequest, and the last field in the response to a
GetRequest.
</t><t>
Specific codes, known as error-indexes, are used to indicate
when a request cannot be processed because a device does not
understand a request.
</t><t>
While this is very practical for SNMP, fully qualified
OIDs are not always well suited to be used as an indicator
for private use options. In many other uses, the source of
authority has been truncated to just the
<xref target="pen">PEN</xref>.
</t>
</section>
<section anchor="radius" title="RADIUS">
<t>
<xref target="RFC2058">The Remote Authentication Dial In User Service (RADIUS)</xref>
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).
</t><t>
The updated RADIUS document, <xref target="RFC2865" />,
gives guidance for using the VSA.
<list style="symbols">
<t>
Servers not equipped to interpret the vendor-specific
information sent by a client MUST ignore it (although it
may be reported).
</t><t>
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.
</t><t>
The Attribute-Specific field is dependent on the
vendor's definition of that attribute.
</t><t>
It SHOULD be encoded as a sequence of vendor type / vendor length / value fields.
</t><t>
Multiple subattributes MAY be encoded within a single
Vendor-Specific Attribute, although they do not have to
be.
</t>
</list>
</t><t>
There are many attributes defined in RADIUS
<xref target="RFC2058" />
which may be considered to be standard options. Each of
these attributes is specified within a "type length value"
(tlv) container. For this protocol, the attribute "type" is
a specific numerical value which differentiates it from
other attributes. As an example, the User-Name (type 1) and
User-Password (type 2) may be considered to be standard
options as they are well defined within the specification.
</t><t>
Type 26 denotes the Vendor Specified Attribute. It is
"available to allow vendors to support their own extended
Attributes not suitable for general usage". The PEN starts
the "value" which should then include a subsequent nested
tlv so the vendor may define and enumerate their own options
within that field.
</t>
<t>
As noted above, the globally unique origin for
<xref target="RFC2865">RADIUS</xref> 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 tlv's. 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"}. Since there is nothing to prevent
vendors from registering multiple PENs, each vendor may have
a plethora of {type="1"}. However, that is actually not
needed since the focus may be extended by enumerating
multiple types. For example, the vendor attribute may
contain {PEN="M", type="1"(value), type="2"(value),
type="3"(value)}.
</t><t>
The values for each type are bounded by the length of the
attribute. Since the entire vendor attribute is defined by
the vendor, the values may be human readable or not. Since
the protocol tends to be machine-to-machine, 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, would be a signal of
some sort to the receiver.
</t>
</section>
<section anchor="mobile" title="Mobile IP">
<t>
<xref target="RFC3115">Mobile IP Vendor Specific Extensions</xref>
defines two extensions that can be used for making
organization specific extensions by vendors/organizations
for their own specific purposes for Mobile IP
<xref target="RFC2002" />. Mobile IP has been revised
several times and is currently specified in
<xref target="RFC5944">IP Mobility Support for IPv4, Revised</xref>.
</t><t>
In that specification, two tlv's have been defined to
contain private use options. These are collectively called
Vendor/Organization Specific Extensions (VSE).
<list style="symbols">
<t>
When the Critical Vendor/Organization Specific Extension
(CVSE) is encountered but not recognized, the message
containing the extension MUST be silently discarded.
</t><t>
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.
</t>
</list>
Having two VSEs of this nature for private use options is
consistent with the original Mobile IP specification
<xref target="RFC2002" /> which states:
<list><t>
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.
</t></list>
</t>
<t>
The structure of the origin, type, and value of the CVSEs
and NVSEs for <xref target="RFC3115">Mobile IP</xref> may 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 following that.
</t><t>
It should be noted that this does not have to be the case.
Specifying CVSEs and NVSEs in various packets can give a
vendor another dimension in processing these private use
fields. If a vendor placed all CVSEs in a single packet,
and the receiver did not understand any one of them, the
entire packet must be discarded. However, if the vendor
places individual CVSEs in separate packets, only CVSEs that
are not understood by the receiver will be discarded.
</t><t>
Similarly, a vendor may choose to not stack NVSEs so that a
receiver won't discard the entire cluster of NVSEs if a
single one is not understood.
</t><t>
The values are constrained by the length of the types or
subtypes.
</t>
</section>
<section anchor="dhcp" title="DHCP">
<t>
The introduction to
<xref target="RFC3925">Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)</xref>
states:
<list>
<t>
The DHCP protocol for IPv4, <xref target="RFC2131" />,
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)
<xref target="RFC2132" />. 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.
</t>
</list>
</t><t>
This meant that
<xref target="RFC2131">Dynamic Host Configuration Protocol</xref>
specified that there was one instance of the vendor type,
and the receiver used that name space 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.
</t><t>
This situation was resolved with the publication of
<xref target="RFC3925">Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)</xref>
which states:
<list>
<t>
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.
</t>
</list>
</t><t>
That specification (<xref target="RFC3925" />) then used the
PEN <xref target="IANApen" /> to define a unique name space
for private use options in this protocol. Similar to other
protocols of this era, tlv containers were used.
</t><t>
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.
</t>
</section>
<section anchor="syslog" title="Syslog">
<t>
<xref target="RFC5424">The Syslog Protocol</xref> also uses
the PEN to uniquely qualify the name space 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 name spaces 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.
</t><t>
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 really interested.
</t>
<t>
The <xref target="RFC5424">Syslog protocol</xref> 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.
</t>
</section>
</section>
<section anchor="dns" title="Domain Name Strings">
<t>
An alternative to using numerical indicators is to use textual
strings. Again, the goal for using these strings is to
disambiguate the identifiers and allow freedom of expression by
the vendors and experimenters using them.
</t>
<section anchor="ssh" title="Secure Shell">
<t>
<xref target="RFC4251">The Secure Shell (SSH) Protocol Architecture</xref>
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
name space field. For example, in
<xref target="RFC4254">The Secure Shell (SSH) Connection Protocol</xref>
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".
</t><t>
Obviously, these character strings are domain names
<xref target="RFC1034" /> <xref target="RFC1035" />. This
is specified in
<xref target="RFC4251">The Secure Shell (SSH) Protocol Architecture</xref>.
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.
</t>
<t>
In the <xref target="RFC4250">SSH protocol</xref>, 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
<xref target="RFC4250" />.
</t>
</section>
</section>
<section anchor="urn" title="URN-based Name Spaces">
<t>
Uniform Resource Names (URNs) have also been used to convey options.
(Need to add a lot here.)
</t>
<section anchor="yang" title="YANG and NETCONF">
<t>
<xref target="RFC6020">YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</xref>
and
<xref target="RFC6241">Network Configuration Protocol
(NETCONF)</xref> use URIs to indicate private use name
spaces. The following is given as an example of a YANG and
NETCONF configuration.
<figure><artwork><![CDATA[
module my-config {
namespace "http://example.com/schema/config";
prefix "co";
container system { ... }
container routing { ... }
}
That example could be encoded in NETCONF as the following.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>This eternal association
<system xmlns="http://example.com/schema/config">
<!-- system data here -->
</system>
<routing xmlns="http://example.com/schema/config">
<!-- routing data here -->
</routing>
</config>
</edit-config>
</rpc>
]]></artwork></figure>
</t><t>
Section 8.3 of <xref target="RFC6020">YANG</xref> 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.
</t><t>
Similarly, <xref target="RFC6241">NETCONF</xref> contains
much information about processing requests that cannot be
completed because elements or values are not recognized.
</t>
<t>
Both <xref target="RFC6020">YANG</xref> and
<xref target="RFC6241">NETCONF</xref> use URIs to enumerate
private use options of a device. The use of this comes from
<xref target="W3C.REC-xpath-19991116">XPATH</xref>.
</t><t>
In both of these, the source 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.
</t><t>
The following is used to demonstrate this. First the YANG
module is shown, then a subset of the NETCONF is shown.
</t><t>
<figure><artwork><![CDATA[
YANG module:
// Contents of "acme-system.yang"
module acme-system {
namespace "http://acme.example.com/system";
prefix "acme";
organization "ACME Inc.";
contact "joe@acme.example.com";
description
"The module for entities implementing the ACME system.";
revision 2007-06-09 {
description "Initial revision.";
}
container system {
leaf host-name {
type string;
description "Hostname for this system";
}
leaf-list domain-search {
type string;
description "List of domain names to search";
}
container login {
leaf message {
type string;
description
"Message given at start of login session";
}
list user {
key "name";
leaf name {
type string;
}
leaf full-name {
type string;
}
leaf class {
type string;
}
}
}
}
}
NETCONF exchange:
<system>
<login>
<message>Good morning</message>
</login>
</system>
]]></artwork></figure>
</t><t>
In this example, YANG describes the source of authority and
focus for the login message, and the NETCONF exchange populates
that specific value.
</t><t>
As noted above, both of these specifications have good
descriptions of actions to take if a name space is not
recognized.
</t>
</section>
</section>
</section>
<section anchor="thinkaboutit" title="Issues to Consider">
<t>
This document is not an encouragement or recommendation to define
private use fields in IETF protocols. Rather, since private use
options are useful to the community and seem to be gaining
popularity, this document is an attempt to document the ways in
which they have been successful so others may benefit.
</t><t>
Private use options are a way to allow vendors, network operators,
and experimenters to convey dynamic information without going
through a rigorous process to register each variable. There is no
"one size fits all" mechanism. The use of a very specific and fixed
format works very well 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.
</t><t>
There seem to be four essential features to using a private use
option.
<list style="symbols">
<t>
One requirement 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.
</t><t>
Instructions are needed on how to deal with private use options
that are not understood by a receiver. In some cases, a
receiver may not need to understand the options immediately upon
receipt as in the case of Syslog. In other cases, the options
are immediately used and instructions must be clear on what to
do if the receiver cannot process them. It appears that Mobile
IP has the best thought-through instructions on this.
</t><t>
Private use options must 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 name space field. These are
becoming known as subattributes. This appears to be working in
practice and it may be assumed that this has become a de facto
rule for RADIUS.
</t><t>
In most cases, a unique option (both standard and private use)
will only be used once within the context of an exchange.
RADIUS and DHCP either state or strongly imply this. However,
while it is not explicitly discussed, there is nothing to
prevent this within Syslog. Some guidance should be given about
this in describing private use options in protocols.
</t>
</list>
</t><t>
Clear documentation in full and open standards is needed to achieve
uniformity and interoperability in these features. Obviously
implementers will need to adhere closely to these standards for
complete interoperability.
</t><t>
Finally, the usage of any private use values on the wire before any
name space is properly reserved with the IANA is entirely
inadvisable.
</t>
<section anchor="means3" title="Value of the Option">
<t>
The value of each private use option must be well defined and
bounded. It is advisable that it be extensible to accomodate
future requirements.
</t><t>
Generally speaking, values of private use options should follow
the same guidance given for standard options.
</t>
</section>
<section anchor="means4" title="Guidance on Incomplete Understanding">
<t>
Within the protocol, an understanding needs to be established
between the transmitter and receiver about what to do if the
receiver does not understand a name space. 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. While other protocols
have no need for the receiver to have any understanding of any
private use options when it receives them. Each of these
behaviors is represented in the examples in this document.
</t><t>
Regardless of whether or not this understanding is established,
the receiver of any protocol must have a defined path of action
to follow when receiving anything that it may not understand.
</t>
</section>
</section>
<section anchor="notes" title="Authors Notes">
<t>
This section will be removed prior to publication.
</t><t>
This is version -08. I dropped this for some time (while I moved to
California and took on a new job). I'm trying to get this back on
track.
</t>
</section>
<section anchor="sec" title="Security Considerations">
<t>
This document reviews ways that options are being used in various
protocols. As such, there are no security considerations inherent
in this document.
</t><t>
Readers and implementers should be aware of the context of
implementing options in their own protocols.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
This document does not propose a standard and does not require the
IANA to do anything.
</t>
</section>
<section anchor="Acks" title="Acknowledgments">
<t>
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.
</t>
<t>
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.
</t>
<t>
David Harrington, Dan Romascanu, Bert Wijnen, Ralph Droms, Juergen
Schoenwalder, Nevil Brownlee, and Klaas Wierenga.
</t>
</section>
</middle>
<back>
<references title="References">
<reference anchor="IANAtcp" target="http://www.iana.org/assignments/tcp-parameters/tcp-parameters.txt">
<front>
<title>IANA Transmission Control Protocol (TCP) Parameters, TCP Option Kind Numbers</title>
<author fullname="Internet Assigned Numbers Authority">
<organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
</author>
<date year="2011" />
</front>
<format type="TXT" target="http://www.iana.org/assignments/tcp-parameters/tcp-parameters.txt" />
</reference>
<reference anchor="IANAftp" target="http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.txt">
<front>
<title>IANA FTP Commands and Extensions</title>
<author fullname="Internet Assigned Numbers Authority">
<organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
</author>
<date year="2010" />
</front>
<format type="TXT" target="http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.txt" />
</reference>
<reference anchor="IANAslg" target="http://www.iana.org/assignments/syslog-parameters">
<front>
<title>IANA syslog Parameter</title>
<author fullname="Internet Assigned Numbers Authority">
<organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
</author>
<date year="2010" />
</front>
<format type="TXT" target="http://www.iana.org/assignments/syslog-parameters" />
</reference>
<reference anchor="IANAsmi" target="http://www.iana.org/assignments/smi-numbers">
<front>
<title>Network Management Parameters</title>
<author fullname="Internet Assigned Numbers Authority">
<organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
</author>
<date year="2011" />
</front>
<format type="TXT" target="http://www.iana.org/assignments/smi-numbers" />
</reference>
<reference anchor="IANApen" target="http://www.iana.org/assignments/enterprise-numbers">
<front>
<title>IANA PRIVATE ENTERPRISE NUMBERS</title>
<author fullname="Internet Assigned Numbers Authority">
<organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
</author>
<date year="2011" />
</front>
<format type="TXT" target="http://www.iana.org/assignments/enterprise-numbers" />
</reference>
<reference anchor="wpProt" target="http://en.wikipedia.org/wiki/Communications_protocol">
<front>
<title>Wikipedia entry for communication protocol</title>
<author fullname="Wikipedia - the Free Dictionary">
<organization abbrev="Wikipedia">Wikipedia - the Free Dictionary</organization>
</author>
<date year="2011" />
</front>
<format type="TXT" target="http://en.wikipedia.org/wiki/Communications_protocol" />
</reference>
<reference anchor="ISO" target="http://www.iso.org">
<front>
<title>International Standards Organization</title>
<author fullname="ISO">
<organization abbrev="ISO">International Standards Organization</organization>
</author>
<date year="2011" />
</front>
<format type="TXT" target="http://www.iso.org" />
</reference>
<reference anchor="ICANN" target="http://www.icann.org">
<front>
<title>Internet Corporation for Assigned Names and Numbers</title>
<author fullname="ICANN">
<organization abbrev="ICANN">Internet Corporation for Assigned Names and Numbers</organization>
</author>
<date year="2011" />
</front>
<format type="TXT" target="http://www.icann.org" />
</reference>
<?rfc include="reference.RFC.0761" ?>
<?rfc include="reference.RFC.0791" ?>
<?rfc include="reference.RFC.0822" ?>
<?rfc include="reference.RFC.0868" ?>
<?rfc include="reference.RFC.0959" ?>
<?rfc include="reference.RFC.1034" ?>
<?rfc include="reference.RFC.1035" ?>
<?rfc include="reference.RFC.1067" ?>
<?rfc include="reference.RFC.1155" ?>
<?rfc include="reference.RFC.2002" ?>
<?rfc include="reference.RFC.2131" ?>
<?rfc include="reference.RFC.2132" ?>
<?rfc include="reference.RFC.2058" ?>
<?rfc include="reference.RFC.2434" ?>
<?rfc include="reference.RFC.2578" ?>
<?rfc include="reference.RFC.2865" ?>
<?rfc include="reference.RFC.3115" ?>
<?rfc include="reference.RFC.3925" ?>
<?rfc include="reference.RFC.4250" ?>
<?rfc include="reference.RFC.4251" ?>
<?rfc include="reference.RFC.4254" ?>
<?rfc include="reference.RFC.5424" ?>
<?rfc include="reference.RFC.5944" ?>
<?rfc include="reference.RFC.6020" ?>
<?rfc include="reference.RFC.6241" ?>
<?rfc include="reference.W3C.REC-xpath-19991116" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:35:29 |