Network Working Group C. Lonvick Internet-Draft February 25, 2019 Intended status: Informational Expires: August 29, 2019 A Taxonomy on Private Use Fields in Protocols draft-lonvick-private-tax-16 Abstract This document provides clarification about private use fields in IETF protocols. 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 https://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 August 29, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November Lonvick Expires August 29, 2019 [Page 1] Internet-Draft Private Use Fields February 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Nomenclature . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Note on References . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . 11 4.7. YANG and NETCONF . . . . . . . . . . . . . . . . . . . . 12 4.8. Extensible Provisioning Protocol . . . . . . . . . . . . 12 5. Observations . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Authoritative Guidance . . . . . . . . . . . . . . . . . . . 15 7. Authors Notes . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction As with any protocol detail, the effectiveness of private use fields depends upon a shared understanding of their syntax and semantics by all participating implementations. For general use in the open Internet, this requires that such fields be fully specified in openly available documents. This discussion provides examples of some protocols to explore the role of private use options. Lonvick Expires August 29, 2019 [Page 2] Internet-Draft Private Use Fields February 2019 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 discussion uses examples of some protocols to exemplify how some private use options are used. 1.1. 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. 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 discussion, but the intent is to identify an authoritative source for the namespace. 1.2. 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. Lonvick Expires August 29, 2019 [Page 3] Internet-Draft Private Use Fields February 2019 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 long as all network participants could easily differentiate between the entities using the option. "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC2434] {[RFC8126]} 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] {[RFC8126]} is from "STANDARD FOR THE FORMAT OF Lonvick Expires August 29, 2019 [Page 4] Internet-Draft Private Use Fields February 2019 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. 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. If the goal for an origin is to disambiguate each focus of a namespace, then the referent most often seen has been globally unique, and not dependent upon local interpretation. Likely, the first private use option with a globally unique source 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 Lonvick Expires August 29, 2019 [Page 5] Internet-Draft Private Use Fields February 2019 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], and in "Private Enterprise Number (PEN) practices and Internet Assigned Numbers Authority (IANA) registration considerations" [I-D.liang-iana-pen]. An alternative to using a numerical indicator such as the OBJECT IDENTIFIER or PEN, is to use textual strings such as names. Domain names may be more ephemeral than eternal. Unlike PENs that usually become unserviceable when their owning organization goes out of business, domain names that fall into disuse may be acquired and used by entirely different organizations. Similar to the use of PENs, there have not been any problems reported from this from normal use. 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 usually been seen to 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. Lonvick Expires August 29, 2019 [Page 6] Internet-Draft Private Use Fields February 2019 4. Examples of Private Use Options This section contains a review of RFCs that allow the use of private use options. 4.1. SNMP SNMP is syntactically complex but has features in the GetRequest PDU that are consistent with the observed characteristics of private use options. The structure of management information (SMI) is currently defined by 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 [IANAsmi]. 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. The Internet subtree of private enterprise OBJECT IDENTIFIERs starts with the prefix: 1.3.6.1.4.1. and is followed by a Private Enterprise Number [IANApen] (PEN) and then the objects defined by that enterprise. 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 focus and a placeholder for its value; the varbind. In a GetRequest the SNMP Manager (the client) fills the first part of the varbind with the object identifier. The other portion is transmitted with an ASN.1 NULL value. In a typical case, the SNMP Agent (the server) responds by replacing the NULL with the actual value in the response. Since this field is defined by the vendor, it may actually be a concatenation of values. The SetRequest PDU is similar to the GetRequest PDU in that it has an OID and may use a PID to identify the objects, however, the varbind is populated differently than in a GetRequest PDU. The other PDUs Lonvick Expires August 29, 2019 [Page 7] Internet-Draft Private Use Fields February 2019 also use the OID and may use a PID, but behave differently than the GetRequest PID. 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). 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" (TLV) 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 practically suggested that the field contain embedded TLVs. 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. 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] as follows: o Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Lonvick Expires August 29, 2019 [Page 8] Internet-Draft Private Use Fields February 2019 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. o Multiple subattributes MAY be encoded within a single Vendor- Specific Attribute, although they do not have to be. 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). 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 Lonvick Expires August 29, 2019 [Page 9] Internet-Draft Private Use Fields February 2019 values may be stacked within the field. The values are constrained by the respective lengths 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. 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. The DHCP [RFC3925] specification 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. DHCP [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. Lonvick Expires August 29, 2019 [Page 10] Internet-Draft Private Use Fields February 2019 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, 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 character strings are domain names as defined in [RFC1034] and [RFC1035]. This is specified in "The Secure Shell (SSH) Protocol Architecture" [RFC4251]. 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 Lonvick Expires August 29, 2019 [Page 11] Internet-Draft Private Use Fields February 2019 experimental or classified extensions can be defined without fear of conflicts with other implementations. 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]. Generally, the guidance given is that if a private use option is not understood the receiver is to convey an error code to its peer. 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. 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 Lonvick Expires August 29, 2019 [Page 12] Internet-Draft Private Use Fields February 2019 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 element. In this protocol, and the extensions, the start of authority is the domain name in the URI and the focus is the full URI path. Guidance has been provided about incomplete understanding. First, a section is provided on responses for received messages that are not understandable, are beyond boundaries, or are not in compliance with policy. Additionally, guidance is given about incomplete understanding of a response: Command success or failure MUST NOT be assumed if no response is returned or if a returned response is malformed. Protocol idempotency ensures the safety of retrying a command in cases of response-delivery failure. The associated RFCs of "Extensible Provisioning Protocol (EPP) Domain Name Mapping" [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. Lonvick Expires August 29, 2019 [Page 13] Internet-Draft Private Use Fields February 2019 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 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 accommodate 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 have been called 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. Lonvick Expires August 29, 2019 [Page 14] Internet-Draft Private Use Fields February 2019 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. This is version -16. I have received ISE feedback and am integrating that into this document. Unfortunately, that's going to take a while as life and the day job keep getting in the way. 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. While it is not a problem that can be technically addressed, fraudulently purporting to be an owner of a domain name, a PEN, or other identifier may allow the misuse of private namespaces. 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. Lonvick Expires August 29, 2019 [Page 15] Internet-Draft Private Use Fields February 2019 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, Brian Carpenter, Randy Presuhn, and Dave Crocker. 11. References 11.1. Normative References [RFC4775] Bradner, S., Carpenter, B., Ed., and T. Narten, "Procedures for Protocol Extensions and Variations", BCP 125, RFC 4775, DOI 10.17487/RFC4775, December 2006, . [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, . 11.2. Informative References [I-D.liang-iana-pen] Liang, P., Melnikov, A., and D. Conrad, "Private Enterprise Number (PEN) practices and Internet Assigned Numbers Authority (IANA) registration considerations", draft-liang-iana-pen-06 (work in progress), July 2015. [IANApen] Internet Assigned Numbers Authority, "IANA PRIVATE ENTERPRISE NUMBERS", 2011, . [IANAsmi] Internet Assigned Numbers Authority, "Network Management Parameters", 2011, . [IANAtcp] Internet Assigned Numbers Authority, "IANA Transmission Control Protocol (TCP) Parameters, TCP Option Kind Numbers", 2011, . Lonvick Expires August 29, 2019 [Page 16] Internet-Draft Private Use Fields February 2019 [ICANN] Internet Corporation for Assigned Names and Numbers, "Internet Corporation for Assigned Names and Numbers", 2011, . [ISO] International Standards Organization, "International Standards Organization", 2011, . [RFC0761] Postel, J., "DoD standard Transmission Control Protocol", RFC 761, DOI 10.17487/RFC0761, January 1980, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC0822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, August 1982, . [RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC 868, DOI 10.17487/RFC0868, May 1983, . [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1067] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1067, DOI 10.17487/RFC1067, August 1988, . [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, DOI 10.17487/RFC1155, 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, . Lonvick Expires August 29, 2019 [Page 17] Internet-Draft Private Use Fields February 2019 [RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, DOI 10.17487/RFC2002, October 1996, . [RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2058, DOI 10.17487/RFC2058, January 1997, . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, . [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, DOI 10.17487/RFC2434, October 1998, . [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/RFC2578, April 1999, . [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, DOI 10.17487/RFC2822, April 2001, . [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, . [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization- Specific Extensions", RFC 3115, DOI 10.17487/RFC3115, April 2001, . [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002, . Lonvick Expires August 29, 2019 [Page 18] Internet-Draft Private Use Fields February 2019 [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, . [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, . [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC 3925, DOI 10.17487/RFC3925, October 2004, . [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, . [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, . [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, January 2006, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, . [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 2009, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, . Lonvick Expires August 29, 2019 [Page 19] Internet-Draft Private Use Fields February 2019 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, August 2009, . [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, 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, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, . [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, . Author's Address Chris Lonvick 1307 Kent Oak Dr. Houston, Texas 77077 US Email: lonvick.ietf@gmail.com Lonvick Expires August 29, 2019 [Page 20]