idnits 2.17.1 draft-lonvick-private-tax-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 370: '...sent by a client MUST ignore it (altho...' RFC 2119 keyword, line 373: '... SHOULD make an attempt to operat...' RFC 2119 keyword, line 379: '... o It SHOULD be encoded as a sequen...' RFC 2119 keyword, line 382: '...le subattributes MAY be encoded within...' RFC 2119 keyword, line 398: '... extension MUST be silently disca...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 14, 2019) is 1836 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 761 (Obsoleted by RFC 793, RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 1067 (Obsoleted by RFC 1098) -- Obsolete informational reference (is this intentional?): RFC 2002 (Obsoleted by RFC 3220) -- Obsolete informational reference (is this intentional?): RFC 2058 (Obsoleted by RFC 2138) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Lonvick 3 Internet-Draft April 14, 2019 4 Intended status: Informational 5 Expires: October 16, 2019 7 A Taxonomy on Private Use Fields in Protocols 8 draft-lonvick-private-tax-17 10 Abstract 12 This document provides clarification about private use fields in IETF 13 protocols. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on October 16, 2019. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 This document may contain material from IETF Documents or IETF 48 Contributions published or made publicly available before November 49 10, 2008. The person(s) controlling the copyright in some of this 50 material may not have granted the IETF Trust the right to allow 51 modifications of such material outside the IETF Standards Process. 52 Without obtaining an adequate license from the person(s) controlling 53 the copyright in such materials, this document may not be modified 54 outside the IETF Standards Process, and derivative works of it may 55 not be created outside the IETF Standards Process, except to format 56 it for publication as an RFC or to translate it into languages other 57 than English. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Nomenclature . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Note on References . . . . . . . . . . . . . . . . . . . 3 64 2. Origins of the Private Use Value . . . . . . . . . . . . . . 3 65 3. Observed Characteristics of Private Use Options . . . . . . . 4 66 3.1. Authority . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Path and Value . . . . . . . . . . . . . . . . . . . . . 6 68 4. Examples of Private Use Options . . . . . . . . . . . . . . . 6 69 4.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.2. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.3. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.5. Syslog . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.6. Secure Shell . . . . . . . . . . . . . . . . . . . . . . 11 75 4.7. YANG and NETCONF . . . . . . . . . . . . . . . . . . . . 12 76 4.8. Extensible Provisioning Protocol . . . . . . . . . . . . 12 77 5. Observations . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6. Authoritative Guidance . . . . . . . . . . . . . . . . . . . 14 79 7. Authors Notes . . . . . . . . . . . . . . . . . . . . . . . . 15 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 85 11.2. Informative References . . . . . . . . . . . . . . . . . 16 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 As with any protocol detail, the effectiveness of private use fields 91 depends upon a shared understanding of their syntax and semantics by 92 all participating implementations. For general use in the open 93 Internet, this requires that such fields be fully specified in openly 94 available documents. This discussion provides examples of some 95 protocols to explore the role of private use options. 97 Some protocols have reserved fields for private and experimental use. 98 Indeed, having options reserved for testing and experimentation has 99 been found to be beneficial to the community as has been outlined in 100 "Assigning Experimental and Testing Numbers Considered Useful" 101 [RFC3692]. 103 Fields reserved for private use cannot provide interoperability 104 unless their use is fully qualified in openly available documents. 105 This discussion uses examples of some protocols to exemplify how some 106 private use options are used. 108 1.1. Nomenclature 110 In this document, the following terms are defined to prevent 111 ambiguity. Some of these words have not been used in the referenced 112 works but their meanings can be ascertained and applied. 114 o Standard Option - a field in a protocol frame that may only use 115 values that are strictly defined within a specification. 117 o Private Use Option - a field in a protocol frame that is reserved 118 for private, experimental, testing, or local use only. 120 o Namespace - a fully qualified Standard Option or Private Use 121 Option. 123 1.2. Note on References 125 In many cases throughout this document, RFCs are referenced even 126 though they are not the most current version of their respective 127 protocol. This is usually done to reference the first occurrence of 128 a private use option, or to point out a distinct feature in that 129 specification. When an RFC is referenced that is not the current 130 version, the reference will be followed by the RFC number of the 131 current version in curly braces. 133 2. Origins of the Private Use Value 135 Some standards permit private use options in different ways, while 136 others do not. The "Time Protocol" [RFC0868] is an example of a 137 protocol that only conveys standardized information; there is no way 138 to use private options and no way to add anything other than what is 139 specified in the document. In a more open way, "DOD STANDARD 140 TRANSMISSION CONTROL PROTOCOL" [RFC0761] {[RFC0793]} {[RFC7805]} does 141 have "options" but they must be registered through the IANA [IANAtcp] 142 before use, which does not leave any room for optional information 143 supplied by equipment vendors, network operators, or experimenters. 144 An even more open way may be seen in "Vendor-Identifying Vendor 145 Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)" 146 [RFC3925], which allows for vendor specific options that do not need 147 to be registered with anyone. 149 For the case of TCP [RFC0761] {[RFC0793]} {[RFC7805]}, standard 150 options are expected; senders may use them and receivers may be 151 configured to act upon that information, or to ignore it. If an 152 experimenter wants to add an option, they will have to create a new 153 IETF RFC with specific details, or obtain approval from the IESG to 154 have the IANA add to the registry [IANAtcp]. Similarly, if equipment 155 vendors Foo and Bar were to have a need for a similar option within 156 TCP, they would each have to go through the process to add to the 157 registry. On the other hand, if a properly crafted multipurpose 158 private use option were to be registered, such as in the case of 159 multiple vendor instances within "DHCPv4" [RFC3925], then vendors and 160 experimenters would each be able to use it for their own purposes as 161 long as all network participants could easily differentiate between 162 the entities using the option. 164 "Guidelines for Writing an IANA Considerations Section in RFCs" 165 [RFC2434] {[RFC8126]} describes that values of specific namespaces 166 may either be registered with the IANA, or not. In most cases, there 167 are well defined values for their respective namespaces. However, as 168 the document explains, not all Values require centralized 169 administration. In that document, it seems to be assumed that 170 private use namespaces will be domain specific and it will be up to 171 the administrators of any domain to avoid conflicts. The first 172 example given about private use namespaces refers to "Dynamic Host 173 Configuration Protocol" [RFC2131] and presumably "DHCP Options and 174 BOOTP Vendor Extensions" [RFC2132]. In this the example states that 175 "site-specific options in DHCP have significance only within a single 176 site". As noted below this became a problem that was rectified in a 177 later revision of DHCP. 179 Later works identified a need to place a scope on private use 180 namespaces. The second example of private use namespace in the IANA 181 guidelines [RFC2434] {[RFC8126]} is from "STANDARD FOR THE FORMAT OF 182 ARPA INTERNET TEXT MESSAGES" [RFC0822] {[RFC5322]} which describes X- 183 headers. There was no effort made to control the scope and the use 184 of the namespace was removed when the specification was updated in 185 2001 in "Internet Message Format" [RFC2822] {[RFC5322]}. 187 3. Observed Characteristics of Private Use Options 189 This section summarizes the observed characteristics of some private 190 use options that have been developed and deployed. 192 There appear to be three quantifiable characteristics of private use 193 options: 195 o Authority 197 o Path 199 o Value 201 3.1. Authority 203 A private use option requires an Authority that can create and 204 maintain the option. If the goal for an Authority is to disambiguate 205 each namespace, then the referent most often seen has been globally 206 unique, and not dependent upon local interpretation. 208 Likely, the first private use option with a globally unique source 209 was defined in the "Structure and Identification of Management 210 Information for TCP/IP-based Internets" [RFC1155] which was first 211 used in "A Simple Network Management Protocol" [RFC1067] {[RFC1157]} 212 (SNMP). The globally unique Authority in SNMP is the International 213 Standards Organization [ISO] which is accredited by the United 214 Nations to maintain this structure. 216 While SNMP used the entire OBJECT IDENTIFIER with the prefix, other 217 protocols only used the Private Enterprise Number [IANApen] (PEN) as 218 a truncated identification of an Authority. This reduced the length 219 of the identifier but continued to provide a unique identifier 220 through a globally managed namespace. 222 The PEN is sourced by the Internet Assigned Numbers Authority (IANA). 223 PENs may be viewed as being similar to domain names in that they are 224 acquired by individuals, corporations, or other organizations. 225 However, a notable difference is that when domain names fall into 226 disuse they may be acquired and used by entirely different people or 227 organizations - as per the conditions set forth by the Internet 228 Corporation for Assigned Names and Numbers [ICANN], the source of the 229 domain names. The structure of the PEN registry does not place any 230 limits on the time that a PEN will be active or associated with the 231 requester. This is no different from many other registries 232 maintained by the IANA; they are just a snapshot at the time of the 233 reservation based on the information required by the IANA and 234 provided by the applicant. This eternal association of the PEN, 235 versus the ephemeral association of domain names, has not been shown 236 to present any problems to private use options. This may, in fact, 237 be a feature as this methodology ensures that these namespaces stay 238 unique for the foreseeable future. 240 Some additional information on the PEN may be found in "Enterprise 241 Number for Documentation Use" [RFC5612], and in "Private Enterprise 242 Number (PEN) practices and Internet Assigned Numbers Authority (IANA) 243 registration considerations" [I-D.liang-iana-pen]. 245 An alternative to using a numerical indicator such as the OBJECT 246 IDENTIFIER or PEN, is to use textual strings such as names. 248 Domain names may be more ephemeral than eternal. Unlike PENs that 249 usually become unserviceable when their owning organization goes out 250 of business, domain names that fall into disuse may be acquired and 251 used by entirely different organizations. Similar to the use of 252 PENs, there have not been any problems reported from this from normal 253 use. 255 Uniform Resource Names (URNs) have also been used to convey options. 256 They seem to provide flexibility for many different needs. URNs were 257 first defined in "Uniform Resource Names (URN) Namespace Definition 258 Mechanisms" [RFC3406] {[RFC8141]}. "An IETF URN Sub-namespace for 259 Registered Protocol Parameters" [RFC3553] provides guidance for ways 260 to use URNs as protocol parameters and how to define an Authority. 262 3.2. Path and Value 264 Once the Authority is established as a globally unique source, an 265 actual option, or in some cases multiple options, may be specified. 266 This has usually been seen to be an indicator of what Value is 267 expected. Within the domain established by the Authority, the Path 268 to each Value has been seen to be unique. 270 In a very simple example, the namespace of a private use option may 271 consist of "Authority"+"Path"="Value". The Authority will be unique. 272 The Path will be unique as long as the Authority maintains that 273 uniqueness; e.g., it would be poor form for a private enterprise to 274 define a namespace, then to redefine it at a later time. 276 4. Examples of Private Use Options 278 This section contains a review of RFCs that allow the use of private 279 use options. 281 4.1. SNMP 283 SNMP is syntactically complex but has features in the GetRequest PDU 284 that are consistent with the observed characteristics of private use 285 options. The structure of management information (SMI) is currently 286 defined by the "Structure of Management Information Version 2 287 (SMIv2)" [RFC2578]. SMI is a well described tree of OBJECT 288 IDENTIFIERs (OIDs). OIDs have an Authority and Path for defined 289 object identifiers which this document describes as standard options. 290 It also allows for experimental and vendor specific object 291 identifiers, which are described as private use options in this 292 document. The IANA maintains a registry of these Network Management 293 Parameters [IANAsmi]. 295 As was noted, the globally unique Authority in SNMP is the 296 International Standards Organization [ISO] which is accredited by the 297 United Nations to maintain this structure. 299 The Internet subtree of experimental OBJECT IDENTIFIERs starts with 300 the prefix: 1.3.6.1.3. 302 The Internet subtree of private enterprise OBJECT IDENTIFIERs starts 303 with the prefix: 1.3.6.1.4.1. and is followed by a Private Enterprise 304 Number [IANApen] (PEN) and then the objects defined by that 305 enterprise. After the vendor identifier (the PEN) in the management 306 information base (MIB), a vendor may create many different trees to 307 identify objects. This may result in a very large number of OBJECT 308 IDENTIFIERs, each of which is an identifier, or Value, of a Path. 309 Each of these are uniquely identified by the vendor and do not 310 require registration with any coordinating authority. 312 The last part of each OBJECT IDENTIFIER is the Path and a placeholder 313 for its value; the varbind. In a GetRequest the SNMP Manager (the 314 client) fills the first part of the varbind with the object 315 identifier. The other portion is transmitted with an ASN.1 NULL 316 value. In a typical case, the SNMP Agent (the server) responds by 317 replacing the NULL with the actual value in the response. Since this 318 field is defined by the vendor, it may actually be a concatenation of 319 Values. 321 The SetRequest PDU is similar to the GetRequest PDU in that it has an 322 OID and may use a PID to identify the objects, however, the varbind 323 is populated differently than in a GetRequest PDU. The other PDUs 324 also use the OID and may use a PID, but behave differently than the 325 GetRequest PID. 327 Specific codes, known as error-indexes, are used to indicate when a 328 request cannot be processed because a device does not understand a 329 request. 331 4.2. RADIUS 333 "The Remote Authentication Dial In User Service (RADIUS)" [RFC2058] 334 {[RFC2865]} specification documented how to use just the PEN (without 335 the rest of the SMI path to the root) to allow "vendors" to 336 articulate their own options. In that document, these are called 337 Vendor-Specific Attributes (VSA). 339 There are many attributes defined in RADIUS [RFC2058] {[RFC2865]} 340 which may be considered to be standard options. Each of these 341 attributes is specified within a "type length value" (TLV) container. 342 For this protocol, the attribute "type" is a specific numerical 343 value, which differentiates it from other attributes. 345 One example of a RADIUS standard option is Type 26, which denotes the 346 Vendor Specified Attribute. It is "available to allow vendors to 347 support their own extended Attributes not suitable for general 348 usage". The PEN of the "vendor" starts the "value" which should then 349 include a subsequent nested TLV so the vendor may define and 350 enumerate their own options within that field. 352 As noted above, the globally unique Authority for "RADIUS" [RFC2865] 353 is the PEN. The remainder of the Attribute field after the PEN is 354 deliberately undefined in the specification. It is practically 355 suggested that the field contain embedded TLVs. Each vendor may then 356 have conflicting "types" (e.g. "1") which would be disambiguated by 357 the Authority. For example [PEN="A", type="1"] is different from 358 [PEN="Z", type="1"]. 360 The values for each type are bounded by the length of the attribute. 361 In some cases, it is feasible that a value has no length. In that 362 case, the transmission of the type alone, has been seen to be a 363 signal of some sort to the receiver. 365 The original specification of [RFC2058] {[RFC2865]} provided guidance 366 that invalid packets were to be silently discarded. That was 367 augmented in [RFC2865] as follows: 369 o Servers not equipped to interpret the vendor-specific information 370 sent by a client MUST ignore it (although it may be reported). 372 o Clients which do not receive desired vendor-specific information 373 SHOULD make an attempt to operate without it, although they may do 374 so (and report they are doing so) in a degraded mode. 376 o The Attribute-Specific field is dependent on the vendor's 377 definition of that attribute. 379 o It SHOULD be encoded as a sequence of vendor type / vendor length 380 / value fields. 382 o Multiple subattributes MAY be encoded within a single Vendor- 383 Specific Attribute, although they do not have to be. 385 4.3. Mobile IP 387 "Mobile IP Vendor Specific Extensions" [RFC3115] defines two 388 extensions that can be used for making organization specific 389 extensions by vendors/organizations for their own specific purposes 390 for Mobile IP [RFC2002] {[RFC5944]}. 392 In that specification, two TLVs have been defined to contain private 393 use options. These are collectively called Vendor/Organization 394 Specific Extensions (VSE). 396 o When the Critical Vendor/Organization Specific Extension (CVSE) is 397 encountered but not recognized, the message containing the 398 extension MUST be silently discarded. 400 o When a Normal Vendor/Organization Specific Extension (NVSE) is 401 encountered but not recognized, the extension SHOULD be ignored, 402 but the rest of the Extensions and message data MUST still be 403 processed. 405 Having two VSEs of this nature for private use options is consistent 406 with the original Mobile IP specification [RFC2002] {[RFC5944]} which 407 states: 409 When an Extension numbered in either of these sets within the 410 range 0 through 127 is encountered but not recognized, the message 411 containing that Extension MUST be silently discarded. When an 412 Extension numbered in the range 128 through 255 is encountered 413 which is not recognized, that particular Extension is ignored, but 414 the rest of the Extensions and message data MUST still be 415 processed. 417 The structure of the namespace of the CVSEs and NVSEs for "Mobile IP" 418 [RFC3115] has been seen to be used in a manner very similar to that 419 of RADIUS. The PEN is the Authority and types and values may be 420 stacked within the field. The values are constrained by the 421 respective lengths of the types or subtypes. 423 4.4. DHCP 425 The introduction to "Vendor-Identifying Vendor Options for Dynamic 426 Host Configuration Protocol version 4 (DHCPv4)" [RFC3925] states: 428 The DHCP protocol for IPv4, [RFC2131], defines options that allow 429 a client to indicate its vendor type (option 60), and the DHCP 430 client and server to exchange vendor-specific information (option 431 43) [RFC2132]. Although there is no prohibition against passing 432 multiple copies of these options in a single packet, doing so 433 would introduce ambiguity of interpretation, particularly if 434 conveying vendor-specific information for multiple vendors. 436 This appears to indicate that "Dynamic Host Configuration Protocol" 437 [RFC2131] specified that there was one instance of the vendor type, 438 and the receiver used that Value to set the scope for the fields in 439 the vendor-specific information option. This version of DHCP did not 440 allow for multiple Authorities; only a single Authority was permitted 441 and the types were to be defined subsequent to that. Evidently this 442 was found to be unworkable when different vendors needed to expand 443 private use options in the protocol. 445 This situation was resolved with the publication of "Vendor- 446 Identifying Vendor Options for Dynamic Host Configuration Protocol 447 version 4 (DHCPv4)" [RFC3925] which cautions: 449 The Dynamic Host Configuration Protocol (DHCP) options for Vendor 450 Class and Vendor-Specific Information can be limiting or ambiguous 451 when a DHCP client represents multiple vendors. 453 The DHCP [RFC3925] specification then used the PEN [IANApen] to 454 define a unique namespace for private use options in this protocol. 455 Similar to other protocols of this era, TLV containers were used. 457 When this protocol was updated to conform to the requirements of 458 IPv6, the PEN was again used as the way to identify the Authority of 459 the private use option. 461 DHCP [RFC3925] provides guidance on actions to take if servers and 462 clients do not comprehend a request or a response. 464 Servers not equipped to interpret the vendor-specific information 465 sent by a client MUST ignore it. Clients that do not receive 466 desired vendor-specific information SHOULD make an attempt to 467 operate without it. 469 4.5. Syslog 471 "The Syslog Protocol" [RFC5424] also uses the PEN to uniquely qualify 472 the Path and Value for a private use option. Standard options do not 473 contain the "@" character. Private use options must have the PEN 474 following the "@" character. This allows a vendor or experimenter to 475 have overlapping Values which the PEN will then uniquely identify. 476 For example the standard option of tzKnown may only have associated 477 values of "0" and "1". However tzKnown@32473 may have any value 478 assigned to it by the owner of enterprise number 32473. 480 Syslog transport receivers are supposed to accept all correctly 481 formatted Syslog messages. Unlike RADIUS, the receiving Syslog 482 application does not have to have immediate knowledge of all variable 483 options to continue operations. If a private use option is not 484 immediately known to the receiving application, it may still store 485 the message and an Operator or Administrator may look it up at a 486 later time if they are interested. 488 The Syslog protocol [RFC5424] uses the PEN as the Authority and 489 allows for the focus of the private use option to be fully defined by 490 the vendor within the structured data. Specifically, a vendor may 491 define a "type" of private use option by concatenating it with the 492 PEN by using the @ character. Within the bounds of the structured 493 data, multiple elements may be used that have identifiers and values. 495 4.6. Secure Shell 497 "The Secure Shell (SSH) Protocol Architecture" [RFC4251] uses 498 character strings rather than PENs. Similar to Syslog, but actually 499 predating it, standard options must not have the "@" character in 500 them. Private use options will have an Authority identifier 501 preceding an "@" character followed by a Value field. For example, 502 in "The Secure Shell (SSH) Connection Protocol" [RFC4254] SSH 503 channels may be opened by specifying a channel type when sending the 504 SSH_MSG_CHANNEL_OPEN message. Standard options for the channel type 505 include "session" and "x11". A private use option for a channel type 506 could be "example_session@example.com". 508 The character strings are domain names as defined in [RFC1034] and 509 [RFC1035]. This is specified in "The Secure Shell (SSH) Protocol 510 Architecture" [RFC4251]. The rational for choosing the manner of 511 providing a format for private use options is given in Section 4.2 of 512 [RFC4251]. 514 We have chosen to identify algorithms, methods, formats, and 515 extension protocols with textual names that are of a specific 516 format. DNS names are used to create local Paths and Values where 517 experimental or classified extensions can be defined without fear 518 of conflicts with other implementations. 520 In the SSH protocol [RFC4250], the Authority is a domain name and the 521 focus of the option is dependent upon context. For example, 522 ourcipher-cbc@example.com can only be used when negotiating ciphers, 523 while example_session@example.com can only be used when negotiating 524 channel types, per the examples in [RFC4250]. 526 Generally, the guidance given is that if a private use option is not 527 understood the receiver is to convey an error code to its peer. 529 4.7. YANG and NETCONF 531 One example of a protocol utilizing URNs is "Network Configuration 532 Protocol (NETCONF)" [RFC6241]. NETCONF may utilize "YANG - A Data 533 Modeling Language for the Network Configuration Protocol (NETCONF)" 534 [RFC6020] as a means to describe and convey options. 536 "YANG - A Data Modeling Language for the Network Configuration 537 Protocol (NETCONF)" [RFC6020] and "Network Configuration Protocol 538 (NETCONF)" [RFC6241] use URIs to indicate private use Paths and 539 Values. 541 Section 8.3 of YANG [RFC6020] describes the parsing of the YANG 542 payload. It contains a good deal of information about how to process 543 elements or values that are not recognized. 545 Similarly, NETCONF [RFC6241] contains much information about 546 processing requests that cannot be completed because elements or 547 values are not recognized. 549 Both YANG [RFC6020] and NETCONF [RFC6241] use URIs to enumerate 550 private use options of a device. The use of this comes from XPATH 551 [W3C.REC-xpath-19991116]. In both of these, the start of authority 552 is the domain name in the URI and the Authority is the full URI path. 553 Many private use options may be described within YANG. From that, 554 each private use option may be populated in NETCONF. 556 4.8. Extensible Provisioning Protocol 558 The "Extensible Provisioning Protocol (EPP)" [RFC5730] is another 559 example of a protocol that utilizes URN Path and Values. From the 560 Protocol Description section 2: 562 EPP uses XML namespaces to provide an extensible object management 563 framework and to identify schemas required for XML instance 564 parsing and validation. These namespaces and schema definitions 565 are used to identify both the base protocol schema and the schemas 566 for managed objects. 568 The specification provides clear guidance and an example on how to 569 extend the base protocol and how to map new objects through the use 570 of separate documents. However, commands and responses may be 571 extended through the use of an element. In this 572 protocol, and the extensions, the start of authority is the domain 573 name in the URI and the focus is the full URI path. 575 Guidance has been provided about incomplete understanding. First, a 576 section is provided on responses for received messages that are not 577 understandable, are beyond boundaries, or are not in compliance with 578 policy. Additionally, guidance is given about incomplete 579 understanding of a response: 581 Command success or failure MUST NOT be assumed if no response is 582 returned or if a returned response is malformed. Protocol 583 idempotency ensures the safety of retrying a command in cases of 584 response-delivery failure. 586 The associated RFCs of "Extensible Provisioning Protocol (EPP) Domain 587 Name Mapping" [RFC5731] and "Extensible Provisioning Protocol (EPP) 588 Host Mapping" [RFC5732] provide a mechanism to temporally bind 589 options. 591 5. Observations 593 Private use options are a way to allow vendors, network operators, 594 and experimenters to convey dynamic information without going through 595 any process to register each variable. However, there is no one size 596 fits all. The use of a very specific and fixed format works for 597 RADIUS which requires speed in processing. On the other hand, the 598 open nature of the private use options in Syslog are appropriate for 599 that protocol where event messages need not be fully parsed at the 600 time of reception. 602 As with all good things, the use of private use options comes with a 603 cost. Adding any extra fields to a protocol will require additional 604 processing for both the sender and the receiver. Also, larger 605 packets will take up more bandwidth in transmission. In another 606 aspect, the code needed to deal with private use options may be 607 considered wasteful if it is not used. 609 There appear to be five quantifiable features that have been 610 documented in using a private use option. 612 o One feature is to have a definable way for the community to 613 ascertain the nature of all private use options. For example, 614 several vendors have published their RADIUS VSAs on web pages, 615 which are easy to find. From that, anyone creating a new RADIUS 616 server would have access to, and be able to incorporate the 617 information available. 619 o Instructions have frequently been provided on how to deal with 620 incomplete understanding; where private use options are not 621 understood by a receiver. Within the example protocol 622 specifications given in this document, some behavior has usually 623 been established about what to do if the receiver does not 624 understand a namespace. Some protocols have defined that a 625 receiver will silently discard packets that contain private use 626 options they do not understand. Other protocols have defined that 627 they will only discard the private use option rather than the 628 entire packet. On the other hand some other protocols have no 629 need for the receiver to have any understanding of any private use 630 options when it receives any. 632 o The values of private use options have frequently followed the 633 same guidance given for standard options in their respective 634 specifications. In most of the examples given, the value of each 635 private use option has been well defined and bounded. Most have 636 been defined to be extensible so as to accommodate future 637 requirements. 639 o Private use options may be extensible in a clearly designed way. 640 RADIUS suggests that the string containing the option be another 641 TLV. This allows a vendor to define multiple private use options 642 within their own Path and Value field. These have been called 643 subattributes. 645 o In some cases, a unique option may only be used once within the 646 context of an exchange. This may define a value of an option once 647 and will not change that value during the remainder of the 648 session. RADIUS and DHCP seem to either state this or strongly 649 imply it. However, while it is not explicitly discussed, it 650 appears that nothing prevents this within Syslog, and it seems to 651 be acceptable behavior to resend unique options multiple times 652 within EPP. 654 Clear documentation has been seen to achieve uniformity and 655 interoperability in these features. Obviously implementers will need 656 to adhere closely to these standards for complete interoperability. 658 6. Authoritative Guidance 660 This document is not an encouragement or recommendation to define 661 private use fields in IETF protocols. Rather, since private use 662 options are being used by the community, this document is an attempt 663 to document the ways in which they have been used. 665 However, "Design Considerations for Protocol Extensions" [RFC6709] is 666 intended to provide guidance on designing protocol extensions. It 667 has several examples and pointers to other material that will aid in 668 the development of protocol extensions. 670 "Procedures for Protocol Extensions and Variations" [RFC4775] is a 671 companion document to [RFC6709] and provides the procedures for 672 review and standardization for extensions to be added to protocols. 674 Finally, the usage of any private use values on the wire before any 675 namespace is properly reserved with the IANA is entirely inadvisable. 677 7. Authors Notes 679 This section will be removed prior to publication. 681 This is version -17. I have received ISE feedback and am integrating 682 that into this document. Unfortunately, that's going to take a while 683 as life and the day job keep getting in the way. 685 I'm updating the nomenclature to be consistent and to accomodate the 686 feedback that I've received. 688 8. Security Considerations 690 This document reviews ways that options are being used in various 691 protocols. As such, there are no security considerations inherent in 692 this document. 694 While it is not a problem that can be technically addressed, 695 fraudulently purporting to be an owner of a domain name, a PEN, or 696 other identifier may allow the misuse of private namespaces. 698 Readers and implementers should be aware of the context of 699 implementing options in protocols they are using or that are being 700 developed. 702 9. IANA Considerations 704 This document does not propose a standard and does not require the 705 IANA to do anything. 707 10. Acknowledgments 709 The idea for documenting this came from questions asked in the SIP- 710 CLF Working Group and the author is grateful for the discussion 711 around this topic. 713 The following people have contributed to this document. Listing 714 their names here does not mean that they agree with or endorse the 715 document, but that they have contributed to its substance: 717 David Harrington, Dan Romascanu, Bert Wijnen, Ralph Droms, Juergen 718 Schoenwalder, Nevil Brownlee, Klaas Wierenga, Brian Carpenter, Randy 719 Presuhn, and Dave Crocker. 721 11. References 723 11.1. Normative References 725 [RFC4775] Bradner, S., Carpenter, B., Ed., and T. Narten, 726 "Procedures for Protocol Extensions and Variations", 727 BCP 125, RFC 4775, DOI 10.17487/RFC4775, December 2006, 728 . 730 [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 731 Considerations for Protocol Extensions", RFC 6709, 732 DOI 10.17487/RFC6709, September 2012, 733 . 735 11.2. Informative References 737 [I-D.liang-iana-pen] 738 Liang, P., Melnikov, A., and D. Conrad, "Private 739 Enterprise Number (PEN) practices and Internet Assigned 740 Numbers Authority (IANA) registration considerations", 741 draft-liang-iana-pen-06 (work in progress), July 2015. 743 [IANApen] Authority, I. A. N., "IANA PRIVATE ENTERPRISE NUMBERS", 744 2011, 745 . 747 [IANAsmi] Authority, I. A. N., "Network Management Parameters", 748 2011, . 750 [IANAtcp] Authority, I. A. N., "IANA Transmission Control Protocol 751 (TCP) Parameters, TCP Option Kind Numbers", 2011, 752 . 755 [ICANN] ICANN, "Internet Corporation for Assigned Names and 756 Numbers", 2011, . 758 [ISO] ISO, "International Standards Organization", 2011, 759 . 761 [RFC0761] Postel, J., "DoD standard Transmission Control Protocol", 762 RFC 761, DOI 10.17487/RFC0761, January 1980, 763 . 765 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 766 RFC 793, DOI 10.17487/RFC0793, September 1981, 767 . 769 [RFC0822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET 770 TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, 771 August 1982, . 773 [RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, 774 RFC 868, DOI 10.17487/RFC0868, May 1983, 775 . 777 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 778 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 779 . 781 [RFC1035] Mockapetris, P., "Domain names - implementation and 782 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 783 November 1987, . 785 [RFC1067] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 786 "Simple Network Management Protocol", RFC 1067, 787 DOI 10.17487/RFC1067, August 1988, 788 . 790 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification 791 of management information for TCP/IP-based internets", 792 STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990, 793 . 795 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 796 "Simple Network Management Protocol (SNMP)", RFC 1157, 797 DOI 10.17487/RFC1157, May 1990, 798 . 800 [RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, 801 DOI 10.17487/RFC2002, October 1996, 802 . 804 [RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens, 805 "Remote Authentication Dial In User Service (RADIUS)", 806 RFC 2058, DOI 10.17487/RFC2058, January 1997, 807 . 809 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 810 RFC 2131, DOI 10.17487/RFC2131, March 1997, 811 . 813 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 814 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 815 . 817 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 818 IANA Considerations Section in RFCs", RFC 2434, 819 DOI 10.17487/RFC2434, October 1998, 820 . 822 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 823 Schoenwaelder, Ed., "Structure of Management Information 824 Version 2 (SMIv2)", STD 58, RFC 2578, 825 DOI 10.17487/RFC2578, April 1999, 826 . 828 [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, 829 DOI 10.17487/RFC2822, April 2001, 830 . 832 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 833 "Remote Authentication Dial In User Service (RADIUS)", 834 RFC 2865, DOI 10.17487/RFC2865, June 2000, 835 . 837 [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization- 838 Specific Extensions", RFC 3115, DOI 10.17487/RFC3115, 839 April 2001, . 841 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 842 "Uniform Resource Names (URN) Namespace Definition 843 Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002, 844 . 846 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 847 IETF URN Sub-namespace for Registered Protocol 848 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 849 2003, . 851 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 852 Considered Useful", BCP 82, RFC 3692, 853 DOI 10.17487/RFC3692, January 2004, 854 . 856 [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for 857 Dynamic Host Configuration Protocol version 4 (DHCPv4)", 858 RFC 3925, DOI 10.17487/RFC3925, October 2004, 859 . 861 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 862 Protocol Assigned Numbers", RFC 4250, 863 DOI 10.17487/RFC4250, January 2006, 864 . 866 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 867 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 868 January 2006, . 870 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 871 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 872 January 2006, . 874 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 875 DOI 10.17487/RFC5322, October 2008, 876 . 878 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 879 DOI 10.17487/RFC5424, March 2009, 880 . 882 [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for 883 Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 884 2009, . 886 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 887 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 888 . 890 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 891 Domain Name Mapping", STD 69, RFC 5731, 892 DOI 10.17487/RFC5731, August 2009, 893 . 895 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 896 Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, 897 August 2009, . 899 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 900 RFC 5944, DOI 10.17487/RFC5944, November 2010, 901 . 903 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 904 the Network Configuration Protocol (NETCONF)", RFC 6020, 905 DOI 10.17487/RFC6020, October 2010, 906 . 908 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 909 and A. Bierman, Ed., "Network Configuration Protocol 910 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 911 . 913 [RFC7805] Zimmermann, A., Eddy, W., and L. Eggert, "Moving Outdated 914 TCP Extensions and TCP-Related Documents to Historic or 915 Informational Status", RFC 7805, DOI 10.17487/RFC7805, 916 April 2016, . 918 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 919 Writing an IANA Considerations Section in RFCs", BCP 26, 920 RFC 8126, DOI 10.17487/RFC8126, June 2017, 921 . 923 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 924 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 925 . 927 [W3C.REC-xpath-19991116] 928 Clark, J. and S. DeRose, "XML Path Language (XPath) 929 Version 1.0", World Wide Web Consortium Recommendation 930 REC-xpath-19991116, November 1999, 931 . 933 Author's Address 935 Chris Lonvick 936 1307 Kent Oak Dr. 937 Houston, Texas 77077 938 US 940 Email: lonvick.ietf@gmail.com