[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13

Network Working Group                                         C. Lonvick
Internet-Draft                                             June 17, 2017
Intended status: Informational
Expires: December 19, 2017


             A Taxonomy on Private Use Fields in Protocols
                    draft-lonvick-private-tax-12.txt

Abstract

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

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

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

   This Internet-Draft will expire on December 19, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Lonvick                 Expires December 19, 2017               [Page 1]


Internet-Draft             Private Use Fields                  June 2017


   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
     1.2.  Nomenclature . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Note on References . . . . . . . . . . . . . . . . . . . .  4
   2.  Origins of the Private Use Namespace . . . . . . . . . . . . .  4
   3.  Observed Characteristics of Private Use Options  . . . . . . .  5
     3.1.  Start of Authority . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Focus of the Namespace . . . . . . . . . . . . . . . . . .  7
   4.  Examples of Private Use Options  . . . . . . . . . . . . . . .  7
     4.1.  SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  Mobile IP  . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.4.  DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.5.  Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.6.  Secure Shell . . . . . . . . . . . . . . . . . . . . . . . 12
     4.7.  YANG and NETCONF . . . . . . . . . . . . . . . . . . . . . 12
     4.8.  Extensible Provisioning Protocol . . . . . . . . . . . . . 13
   5.  Observations . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Authoritative Guidance . . . . . . . . . . . . . . . . . . . . 15
   7.  Authors Notes  . . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     11.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20









Lonvick                 Expires December 19, 2017               [Page 2]


Internet-Draft             Private Use Fields                  June 2017


1.  Introduction

   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"
   [RFC3692].

   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.

1.1.  Requirements Language

   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" [RFC2119].

1.2.  Nomenclature

   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.

   o  Standard option - a field in a protocol frame that may only use
      values that are strictly defined within a specification

   o  Private use option - a field in a protocol frame that is reserved
      for private, experimental, testing, or local use only namespaces.

   o  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.




Lonvick                 Expires December 19, 2017               [Page 3]


Internet-Draft             Private Use Fields                  June 2017


   The name "Start of Authority" comes from the domain name system
   configuration file which describes a "SoA" in "DOMAIN NAMES -
   CONCEPTS AND FACILITIES" [RFC1034] and "DOMAIN NAMES - IMPLEMENTATION
   AND SPECIFICATION" [RFC1035].  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.

1.3.  Note on References

   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.


2.  Origins of the Private Use Namespace

   Some standards permit private use options in different ways, while
   others do not.  The "Time Protocol" [RFC0868] 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" [RFC0761] {[RFC0793]} {[RFC7805]} does
   have "options" but they must be registered through the IANA [IANAtcp]
   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)"
   [RFC3925], which allows for vendor specific options that do not need
   to be registered with anyone.

   For the case of TCP [RFC0761] {[RFC0793]} {[RFC7805]}, 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 [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 "DHCPv4" [RFC3925], then vendors and
   experimenters would each be able to use it for their own purposes as



Lonvick                 Expires December 19, 2017               [Page 4]


Internet-Draft             Private Use Fields                  June 2017


   long as all network participants could easily differentiate between
   the entities using the option.

   "Guidelines for Writing an IANA Considerations Section in RFCs"
   [RFC2434] {[RFC5226]} 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"
   [RFC2131] and presumably "DHCP Options and BOOTP Vendor Extensions"
   [RFC2132].  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 [RFC2434] {[RFC5226]} is from "STANDARD FOR THE FORMAT OF
   ARPA INTERNET TEXT MESSAGES" [RFC0822] {[RFC5322]} 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" [RFC2822] {[RFC5322]}.


3.  Observed Characteristics of Private Use Options

   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:

   o  Start of Authority

   o  Focus of the Namespace

   o  Value of the Option

3.1.  Start of Authority

   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.



Lonvick                 Expires December 19, 2017               [Page 5]


Internet-Draft             Private Use Fields                  June 2017


   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" [RFC1155] which was first used in "A Simple Network
   Management Protocol" [RFC1067] {[RFC1157]} (SNMP).  The globally
   unique origin in SNMP is the International Standards Organization
   [ISO] 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 [IANApen] (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 [ICANN], 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" [RFC5612].

   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.




Lonvick                 Expires December 19, 2017               [Page 6]


Internet-Draft             Private Use Fields                  June 2017


   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" [RFC3406] {[RFC8141]}.  "An IETF URN Sub-namespace for
   Registered Protocol Parameters" [RFC3553] provides guidance for ways
   to use URNs as protocol parameters and how to define a start of
   authority.

3.2.  Focus of the Namespace

   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.


4.  Examples of Private Use Options

   This section contains a review of RFCs that allow the use of private
   use options.

4.1.  SNMP

   As was noted, the globally unique origin in SNMP is the International
   Standards Organization [ISO] 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 [IANApen] (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)"
   [RFC2578].  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



Lonvick                 Expires December 19, 2017               [Page 7]


Internet-Draft             Private Use Fields                  June 2017


   [IANAsmi].

   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.

4.2.  RADIUS

   "The Remote Authentication Dial In User Service (RADIUS)" [RFC2058]
   {[RFC2865]} 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, [RFC2865], gives guidance for using the
   VSA.

   o  Servers not equipped to interpret the vendor-specific information
      sent by a client MUST ignore it (although it may be reported).

   o  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.

   o  The Attribute-Specific field is dependent on the vendor's
      definition of that attribute.

   o  It SHOULD be encoded as a sequence of vendor type / vendor length
      / value fields.



Lonvick                 Expires December 19, 2017               [Page 8]


Internet-Draft             Private Use Fields                  June 2017


   o  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 [RFC2058] {[RFC2865]}
   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" [RFC2865] 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 [RFC2058] {[RFC2865]} provided guidance
   that invalid packets were to be silently discarded.  That was
   augmented in [RFC2865] to say that RADIUS clients and servers may
   ignore Attributes with an unknown type.

4.3.  Mobile IP

   "Mobile IP Vendor Specific Extensions" [RFC3115] defines two
   extensions that can be used for making organization specific
   extensions by vendors/organizations for their own specific purposes
   for Mobile IP [RFC2002] {[RFC5944]}.

   In that specification, two TLVs have been defined to contain private
   use options.  These are collectively called Vendor/Organization
   Specific Extensions (VSE).





Lonvick                 Expires December 19, 2017               [Page 9]


Internet-Draft             Private Use Fields                  June 2017


   o  When the Critical Vendor/Organization Specific Extension (CVSE) is
      encountered but not recognized, the message containing the
      extension MUST be silently discarded.

   o  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 [RFC2002] {[RFC5944]} 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" [RFC3115] 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.

4.4.  DHCP

   The introduction to "Vendor-Identifying Vendor Options for Dynamic
   Host Configuration Protocol version 4 (DHCPv4)" [RFC3925] states:

      The DHCP protocol for IPv4, [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) [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.

   This appears to indicate that "Dynamic Host Configuration Protocol"
   [RFC2131] 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.



Lonvick                 Expires December 19, 2017              [Page 10]


Internet-Draft             Private Use Fields                  June 2017


   This situation was resolved with the publication of "Vendor-
   Identifying Vendor Options for Dynamic Host Configuration Protocol
   version 4 (DHCPv4)" [RFC3925] 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 ([RFC3925]) then used the PEN [IANApen] 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.

   [RFC3925] 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.

4.5.  Syslog

   "The Syslog Protocol" [RFC5424] 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 [RFC5424] 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,



Lonvick                 Expires December 19, 2017              [Page 11]


Internet-Draft             Private Use Fields                  June 2017


   multiple elements may be used that have identifiers and values.

4.6.  Secure Shell

   "The Secure Shell (SSH) Protocol Architecture" [RFC4251] 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" [RFC4254] 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 [RFC4251].

      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 [RFC1034] and
   [RFC1035].  This is specified in "The Secure Shell (SSH) Protocol
   Architecture" [RFC4251].

   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 [RFC4250], 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 [RFC4250].

4.7.  YANG and NETCONF

   One example of a protocol utilizing URNs is "Network Configuration
   Protocol (NETCONF)" [RFC6241].  NETCONF may utilize "YANG - A Data
   Modeling Language for the Network Configuration Protocol (NETCONF)"
   [RFC6020] as a means to describe and convey options.

   "YANG - A Data Modeling Language for the Network Configuration
   Protocol (NETCONF)" [RFC6020] and "Network Configuration Protocol
   (NETCONF)" [RFC6241] use URIs to indicate private use namespaces.




Lonvick                 Expires December 19, 2017              [Page 12]


Internet-Draft             Private Use Fields                  June 2017


   Section 8.3 of YANG [RFC6020] 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 [RFC6241] contains much information about
   processing requests that cannot be completed because elements or
   values are not recognized.

   Both YANG [RFC6020] and NETCONF [RFC6241] use URIs to enumerate
   private use options of a device.  The use of this comes from XPATH
   [W3C.REC-xpath-19991116].

   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.

4.8.  Extensible Provisioning Protocol

   The "Extensible Provisioning Protocol (EPP)" [RFC5730] 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



Lonvick                 Expires December 19, 2017              [Page 13]


Internet-Draft             Private Use Fields                  June 2017


   Name Mapping" [RFC5731] and "Extensible Provisioning Protocol (EPP)
   Host Mapping" [RFC5732] provide a mechanism to temporally bind
   options.


5.  Observations

   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.

   o  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.

   o  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.

   o  The values of private use options have frequently followed the
      same guidance given for standard options in their respective



Lonvick                 Expires December 19, 2017              [Page 14]


Internet-Draft             Private Use Fields                  June 2017


      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.

   o  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.

   o  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.


6.  Authoritative Guidance

   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" [RFC6709] 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" [RFC4775] is a
   companion document to [RFC6709] 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.


7.  Authors Notes

   This section will be removed prior to publication.



Lonvick                 Expires December 19, 2017              [Page 15]


Internet-Draft             Private Use Fields                  June 2017


   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.


8.  Security Considerations

   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.


9.  IANA Considerations

   This document does not propose a standard and does not require the
   IANA to do anything.


10.  Acknowledgments

   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.


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4775]  Bradner, S., Carpenter, B., Ed., and T. Narten,



Lonvick                 Expires December 19, 2017              [Page 16]


Internet-Draft             Private Use Fields                  June 2017


              "Procedures for Protocol Extensions and Variations",
              BCP 125, RFC 4775, DOI 10.17487/RFC4775, December 2006,
              <http://www.rfc-editor.org/info/rfc4775>.

   [RFC6709]  Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
              Considerations for Protocol Extensions", RFC 6709,
              DOI 10.17487/RFC6709, September 2012,
              <http://www.rfc-editor.org/info/rfc6709>.

11.2.  Informative References

   [IANAtcp]  Internet Assigned Numbers Authority, "IANA Transmission
              Control Protocol (TCP) Parameters, TCP Option Kind
              Numbers", 2011, <http://www.iana.org/assignments/
              tcp-parameters/tcp-parameters.txt>.

   [IANAsmi]  Internet Assigned Numbers Authority, "Network Management
              Parameters", 2011,
              <http://www.iana.org/assignments/smi-numbers>.

   [IANApen]  Internet Assigned Numbers Authority, "IANA PRIVATE
              ENTERPRISE NUMBERS", 2011,
              <http://www.iana.org/assignments/enterprise-numbers>.

   [ISO]      International Standards Organization, "International
              Standards Organization", 2011, <http://www.iso.org>.

   [ICANN]    Internet Corporation for Assigned Names and Numbers,
              "Internet Corporation for Assigned Names and Numbers",
              2011, <http://www.icann.org>.

   [RFC0761]  Postel, J., "DoD standard Transmission Control Protocol",
              RFC 761, January 1980.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <http://www.rfc-editor.org/info/rfc793>.

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

   [RFC0868]  Postel, J. and K. Harrenstien, "Time Protocol", STD 26,
              RFC 868, May 1983.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and



Lonvick                 Expires December 19, 2017              [Page 17]


Internet-Draft             Private Use Fields                  June 2017


              specification", STD 13, RFC 1035, November 1987.

   [RFC1067]  Case, J., Fedor, M., Schoffstall, M., and J. Davin,
              "Simple Network Management Protocol", RFC 1067,
              August 1988.

   [RFC1155]  Rose, M. and K. McCloghrie, "Structure and identification
              of management information for TCP/IP-based internets",
              STD 16, RFC 1155, May 1990.

   [RFC1157]  Case, J., Fedor, M., Schoffstall, M., and J. Davin,
              "Simple Network Management Protocol (SNMP)", RFC 1157,
              DOI 10.17487/RFC1157, May 1990.

   [RFC2002]  Perkins, C., "IP Mobility Support", RFC 2002,
              October 1996.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC2058]  Rigney, C., Rubens, A., Simpson, W., and S. Willens,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2058, January 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [RFC2822]  Resnick, P., Ed., "Internet Message Format", RFC 2822,
              DOI 10.17487/RFC2822, April 2001,
              <http://www.rfc-editor.org/info/rfc2822>.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3115]  Dommety, G. and K. Leung, "Mobile IP Vendor/
              Organization-Specific Extensions", RFC 3115, April 2001.

   [RFC3406]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
              "Uniform Resource Names (URN) Namespace Definition



Lonvick                 Expires December 19, 2017              [Page 18]


Internet-Draft             Private Use Fields                  June 2017


              Mechanisms", BCP 66, RFC 3406, October 2002.

   [RFC3553]  Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
              IETF URN Sub-namespace for Registered Protocol
              Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553,
              June 2003, <http://www.rfc-editor.org/info/rfc3553>.

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692, DOI 10.17487/
              RFC3692, January 2004,
              <http://www.rfc-editor.org/info/rfc3692>.

   [RFC3925]  Littlefield, J., "Vendor-Identifying Vendor Options for
              Dynamic Host Configuration Protocol version 4 (DHCPv4)",
              RFC 3925, October 2004.

   [RFC4250]  Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH)
              Protocol Assigned Numbers", RFC 4250, January 2006.

   [RFC4251]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, January 2006.

   [RFC4254]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Connection Protocol", RFC 4254, January 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <http://www.rfc-editor.org/info/rfc5322>.

   [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.

   [RFC5612]  Eronen, P. and D. Harrington, "Enterprise Number for
              Documentation Use", RFC 5612, August 2009.

   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              STD 69, RFC 5730, August 2009.

   [RFC5731]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/
              RFC5731, August 2009,
              <http://www.rfc-editor.org/info/rfc5731>.

   [RFC5732]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)



Lonvick                 Expires December 19, 2017              [Page 19]


Internet-Draft             Private Use Fields                  June 2017


              Host Mapping", STD 69, RFC 5732, August 2009.

   [RFC5944]  Perkins, C., "IP Mobility Support for IPv4, Revised",
              RFC 5944, November 2010.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)",
              RFC 6241, June 2011.

   [RFC7805]  Zimmermann, A., Eddy, W., and L. Eggert, "Moving Outdated
              TCP Extensions and TCP-Related Documents to Historic or
              Informational Status", RFC 7805, DOI 10.17487/RFC7805,
              April 2016, <http://www.rfc-editor.org/info/rfc7805>.

   [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
              (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
              <http://www.rfc-editor.org/info/rfc8141>.

   [W3C.REC-xpath-19991116]
              Clark, J. and S. DeRose, "XML Path Language (XPath)
              Version 1.0", World Wide Web Consortium
              Recommendation REC-xpath-19991116, November 1999,
              <http://www.w3.org/TR/1999/REC-xpath-19991116>.


Author's Address

   Chris Lonvick
   1307 Kent Oak Dr.
   Houston, Texas  77077
   US

   Email: lonvick.ietf@gmail.com














Lonvick                 Expires December 19, 2017              [Page 20]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/