One document matched: draft-lonvick-private-tax-07.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-07.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>213 El Rancho Grande</street>
<city>Kerrville</city><region>Texas</region>
<code>78028</code>
<country>US</country>
</postal>
<email>lonvick.ietf@gmail.com</email>
</address>
</author>
<date month="March" year="2013" />
<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 exemplify 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 <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 supplicant. 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 forever.
</t><t>
Domain names have similar problems as they can be more ephemeral than
eternal. The top level domains are maintained by the Internet
Corporation for Assigned Names and Numbers [ICANN] however the specific
names are assigned much more locally. 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. Again however, like 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
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 names 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>
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 and practicable for SNMP, fully qualified
OIDs are not always well suited to be used as an indicator for private
use options.
</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>
</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 and
practicable. 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.
</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>
<t>
The first version of the <xref target="RFC2131">DHCP protocol</xref>
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. After it was
changed, it becomes very similar to CVSEs and NVSEs described in
<xref target="RFC3115">Mobile IP</xref>, however multiple uses of
the PEN are still not permitted.
</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="uri" title="Uniform Resource Indicators">
<t>
Add some stuff 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 would
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 subattribute will only be named 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 extensible but bounded.
</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 -07. I received feedback from the Independent Submission
Editor and reviewers. Their input changed the structure of this document
greatly. I am in the process of addressing their feedback so this version
is a checkpoint so the draft does not time out.
</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, 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:31 |