idnits 2.17.1 draft-lonvick-private-tax-11.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 459: '...sent by a client MUST ignore it (altho...' RFC 2119 keyword, line 462: '... SHOULD make an attempt to operat...' RFC 2119 keyword, line 468: '... o It SHOULD be encoded as a sequen...' RFC 2119 keyword, line 471: '...le subattributes MAY be encoded within...' RFC 2119 keyword, line 523: '... extension MUST be silently disca...' (4 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 (October 8, 2016) is 2750 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 761 (Obsoleted by RFC 793, RFC 7805) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1067 (Obsoleted by RFC 1098) ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2058 (Obsoleted by RFC 2138) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856) Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Lonvick 3 Internet-Draft October 8, 2016 4 Intended status: Informational 5 Expires: April 11, 2017 7 A Taxonomy on Private Use Fields in Protocols 8 draft-lonvick-private-tax-11.txt 10 Abstract 12 This document attempts to provide some clarification for the way that 13 private use fields have been used in protocols developed in the IETF. 14 It is strictly a taxonomy of what has been published and offers a 15 minimal amount of advice about how to design or use private use 16 options. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 11, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Origins of the Private Use Namespace . . . . . . . . . . . . . 4 66 3. Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Characteristics of Useful Private Use Options . . . . . . . . 7 68 4.1. Source of Authority . . . . . . . . . . . . . . . . . . . 7 69 4.2. Focus of the Namespace . . . . . . . . . . . . . . . . . . 8 70 5. Examples of Successful Private Use Options . . . . . . . . . . 8 71 5.1. Private Enterprise Number . . . . . . . . . . . . . . . . 9 72 5.1.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.1.2. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . 10 74 5.1.3. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 5.1.5. Syslog . . . . . . . . . . . . . . . . . . . . . . . . 13 77 5.2. Domain Name Strings . . . . . . . . . . . . . . . . . . . 14 78 5.2.1. Secure Shell . . . . . . . . . . . . . . . . . . . . . 14 79 5.3. URN-based Namespaces . . . . . . . . . . . . . . . . . . . 14 80 5.3.1. YANG and NETCONF . . . . . . . . . . . . . . . . . . . 15 81 6. Issues to Consider . . . . . . . . . . . . . . . . . . . . . . 17 82 6.1. Value of the Option . . . . . . . . . . . . . . . . . . . 18 83 6.2. Guidance on Incomplete Understanding . . . . . . . . . . . 19 84 7. Authors Notes . . . . . . . . . . . . . . . . . . . . . . . . 19 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 1. Introduction 93 Simply put, communications protocols are standardized ways for 94 computing entities to convey information. Within each communications 95 protocol, there must be standardized pieces of information that will 96 be communicated, and there may be non-standardized pieces that can be 97 communicated. Since one of the goals of standards is to provide 98 interoperability, all parties participating in any communications 99 protocol must be aware of how to deal with all fields in the 100 protocol. Fields reserved for private use cannot provide 101 interoperability unless their use is fully documented in openly 102 available documents. This section uses examples of some well known 103 protocols to demonstrate the differences between protocols that use 104 private use options, and those that don't. 106 Existing standards permit private use options in different ways. The 107 Time Protocol [RFC0868] is an example of a protocol that only conveys 108 standardized information. There is no way to add anything other than 109 what is specified in the document. On the other hand, DOD STANDARD 110 TRANSMISSION CONTROL PROTOCOL [RFC0761] does have "options" but they 111 must be registered through the IANA [IANAtcp] before use, which does 112 not leave any room for optional information supplied by equipment 113 vendors, network operators, or experimenters. Finally, Vendor- 114 Identifying Vendor Options for Dynamic Host Configuration Protocol 115 version 4 (DHCPv4) [RFC3925] does allow for vendor specific options 116 that do not need to be registered with anyone. 118 If a network operator wanted to add specific information to the Time 119 Protocol [RFC0868], they could modify the code of all senders and 120 receivers and run this within their own domain without any problems. 121 However, if an equipment vendor wanted to include information 122 specific to their equipment, they would have to ensure that all 123 senders and receivers within all network domains would either accept 124 the change in the protocol, or would not have problems with it. As a 125 final case, if several equipment vendors desired to add equipment- 126 specific information to this protocol, they would have to take great 127 care that only their own receivers would accept information from 128 their own transmitters. An extension to that would be that if one 129 equipment vendor would like to transmit or receive the same 130 information that another vendor is using. 132 For the case of TCP [RFC0761], standard options are expected; senders 133 may use them and receivers may be configured to act upon that 134 information, or to ignore it. If an experimenter wants to add an 135 option, they will have to create a new IETF RFC with specific 136 details, or obtain approval from the IESG to have the IANA add to the 137 registry [IANAtcp]. Similarly, if equipment vendors Foo and Bar were 138 to have a need for a similar option within TCP, they would each have 139 to go through the process to add to the registry. On the other hand, 140 if a properly crafted multipurpose private use option were to be 141 registered, such as in the case of multiple vendor instances within 142 DHCPv4 [RFC3925], then vendors and experimenters would each be able 143 to use it for their own purposes as long as all network participants 144 could easily differentiate between the entities using the option. 146 This document explores the various ways that protocols have allowed 147 optional information to be included using fields designated as 148 "private use". It uses examples of some well known protocols. In 149 well developed protocols, private use options may be useful in 150 avoiding allocation conflicts, and in dynamically extending a 151 feature. As with all good things, this will come with a cost. 152 Adding any extra fields to a protocol will require additional 153 processing for both the sender and the receiver. Also, larger 154 packets will take up more bandwidth in transmission. In another 155 aspect, a receiver will have to reserve buffers for an expected field 156 in an inbound packet. Since one way of implementing private use 157 options is to only enable the field if it is needed, then the 158 allocation of buffers could be considered wasteful if it is actually 159 not used. 161 2. Origins of the Private Use Namespace 163 Guidelines for Writing an IANA Considerations Section in RFCs 164 [RFC2434] describes that values of specific namespaces may either be 165 registered with the IANA, or not. In most cases, there are well 166 defined values for namespaces. However, as the document explains, 167 not all namespaces require centralized administration. 169 In that document, it seems to be assumed that private use namespaces 170 will be domain specific and it will be up to the administrators of 171 any domain to avoid conflicts. The first example given about private 172 use namespaces refers to Dynamic Host Configuration Protocol 173 [RFC2131] and presumably DHCP Options and BOOTP Vendor Extensions 174 [RFC2132]. In this the example states that "site-specific options in 175 DHCP have significance only within a single site". As noted below 176 this became a problem that was rectified in a later revision of DHCP. 178 Later works identified a need to place a scope on private use 179 namespaces. The second example of private use namespaces in the IANA 180 guidelines [RFC2434] is from STANDARD FOR THE FORMAT OF ARPA INTERNET 181 TEXT MESSAGES [RFC0822] which describes X- headers. Again, there is 182 no effort made to control the namespace. It appears however that the 183 users of X- headers have self-organized; most consistently use 184 features that are universally useful and many have incorporated 185 identifiers for useful features that may overlap. 187 3. Nomenclature 189 In this document, the following words are defined to prevent 190 ambiguity. Some of these words have not been used in the referenced 191 works but their meanings can be easily ascertained and applied. 193 o Communications protocol - a formal description of digital message 194 formats and the rules for exchanging those messages in or between 195 computing systems and in telecommunications [wpProt] 197 Example: The File Transfer Protocol [RFC0959] is an example of 198 a communications protocol. It has well defined fields and 199 standard options. The Syslog Protocol [RFC5424] is another 200 example of a communications protocol. It has well defined 201 fields, standard options, and it also has standard and private 202 use options. (See Section 5.1.5.) 204 o Protocol frame - a defined container of fields used to convey 205 information in a communications protocol 207 Example: An Internet Protocol packet [RFC0791] is considered to 208 be a protocol frame. In the case of The File Transfer Protocol 209 [RFC0959], an FTP message from the client to the server within 210 the Internet Protocol [RFC0791] containing an FTP command is a 211 protocol frame. In the case of The Syslog Protocol [RFC5424], 212 a message from the client to the server within the Internet 213 Protocol [RFC0791] containing a syslog message is also a 214 protocol frame. 216 o Field - any defined container within a communications protocol 217 frame 219 Example: In the case of The File Transfer Protocol [RFC0959], a 220 command will be contained within a field. In the case of The 221 Syslog Protocol [RFC5424], the HOSTNAME is a field. 223 o Standard option - a field in a protocol frame that may only use 224 values that are strictly defined within a specification 226 Example: In the case of The File Transfer Protocol [RFC0959], 227 an FTP command, such as CDUP or QUIT, is a standard option. 228 The reason that a command is a standard option is that only the 229 values listed by the IANA in the registry [IANAftp] may be 230 used. The standard options are not limited to the values 231 defined in the original RFC, but also include any additions to 232 the registry. In the case of The Syslog Protocol [RFC5424], an 233 SD-ID may be a standard option. The example given in Section 234 7.1.4 of [RFC5424] of 236 [timeQuality tzKnown="0" isSynced="0"] 238 is a standard option because all of the fields are listed in 239 the document and in the IANA registry [IANAslg]. 241 o Private use option - a field in a protocol frame that is reserved 242 for private or local use only namespaces 244 Example: In the case of The Syslog Protocol, an SD-ID may be a 245 private use option. Example 3 given in Section 6.5 contains a 246 private use option. 248 <165>1 2003-10-11T22:14:15.003Z mymachine.example.com 249 evntslog - ID47 [exampleSDID@32473 iut="3" eventSource= 250 "Application" eventID="1011"] BOMAn application 251 event log entry... 253 Specifically, the SD-ID starting with "[exampleSDID@32473 ..." 254 is not a specifically defined option in the RFC, nor is it 255 registered in the IANA registry [IANAslg]. It is a way for an 256 equipment vendor to insert their specific information without 257 having to register anything. In this case if the receiver 258 knows the format of that SD-ID then it can immediately 259 interpret its meaning. However, if it does not know how to 260 interpret that SD-ID, it can still log the message and an 261 Operator or Administrator can look up its meaning at a later 262 time. 264 o Namespace - the set of possible values a field may contain; its 265 actual content may be a name, a number or another kind of value 267 Example: In the same Example 3 from Section 6.5 of The Syslog 268 Protocol [RFC5424], "exampleSDID@32473" provides the namespace 269 so the context of the rest of the SD-ID may be interpreted. 270 Specifically, the Private Enterprise Number [IANApen] (PEN) is 271 used to associate the option with a private enterprise, and the 272 text before the "@" identifies the option defined within that 273 private enterprise. 275 Additionally, the terms "Source of Authority" and "Focus of the 276 Namespace" are defined and further discussed below. 278 It should also be noted that some references use the term "name 279 space" to refer to namespace. The IETF has been fairly consistent in 280 using the term "namespace" in documents and this specification 281 follows that precedence. 283 4. Characteristics of Useful Private Use Options 285 Private use options can be separated into discreet pieces of 286 information. The interpretation of each piece of information places 287 its context. The interpretation of the entirety of these pieces of 288 information will uniquely describe the context of the information and 289 the value associated with it. This must provide a single and unique 290 interpretation of the information to each receiver. 292 This section summarizes the observed characteristics of private use 293 options that are successful and deployed. Following sections will 294 explain how these characteristics apply to specific protocols that 295 are commonly used in the Internet. 297 There seem to be three characteristics of successful private use 298 options: 300 A Source of Authority 302 A Focus of the Namespace 304 A Value of the Option 306 As an example, in SNMP the combination of the Source of Authority and 307 the Focus of the Namespace (Focus) represent the OID. The 308 combination of the Source of Authority, the Focus, and the Value of 309 the Option (Value) constitute the VarBind. 311 4.1. Source of Authority 313 A private use option requires a path to an origin that has the 314 authority to create and maintain the option. As shown above, this 315 referent should be unique, and not be dependent upon local 316 interpretation. 318 The name "Source of Authority" comes from the domain name system 319 configuration file which enumerates a "SoA" as the person or entity 320 who has ultimate control and decision making powers over the scope of 321 the domain. Some liberties have been taken with using this name but 322 the intent is to identify an authoritative source for the namespace. 324 The PEN (Section 5.1) is sourced by the Internet Assigned Numbers 325 Authority (IANA). These may be viewed as being similar to domain 326 names in that they are acquired by individuals, corporations, or 327 other organizations. A notable difference is that when domain names 328 fall into disuse they may be acquired and used by entirely different 329 people or organizations - as per the conditions required by the 330 Internet Corporation for Assigned Names and Numbers [ICANN], the 331 source of the domain names. The structure of the PEN registry does 332 not place any limits on the time that a PEN will be active or 333 associated with the requester. This is no different from many other 334 registries maintained by the IANA; they are just a snapshot at the 335 time of the reservation based on the information required by the IANA 336 and provided by the applicant. This eternal association of the PEN, 337 versus the ephemeral association of domain names, has not been shown 338 to present any problems. This may, in fact, be a feature as this 339 methodology ensures that these namespaces stay unique for the 340 foreseeable future. 342 Domain names have similar problems as they can be more ephemeral than 343 eternal. Unlike PENs that become unserviceable when their owning 344 organization goes out of business, domain names that fall into disuse 345 may be acquired and used by entirely different organizations. 346 Similar to the use of PENs there have not been any problems reported 347 from this. 349 It is vital to note that the usage of the option within the private 350 space is the full responsibility of the private entity. In the 351 example of the PEN, each entity registering a PEN must fully quantify 352 the parameters of the use of the option within their purview. 354 4.2. Focus of the Namespace 356 Once the source of authority is established, an actual option, or 357 multiple options, must be specified. This is usually an indicator of 358 what value is expected. Within the domain established by the source 359 of authority, the focus of each value must be unique. In a very 360 simple example, a private use option may consist of 361 "PEN"@"focus"="value". The PEN will be unique and will specify the 362 source of authority. The focus will be unique as long as the source 363 of authority maintains that uniqueness; e.g., it would be poor form 364 for a private enterprise to define a focus, then to redefine it at a 365 later time. 367 In some cases, multiple focuses and values need to be transmitted. 368 When the PEN has been used, this has most often been achieved by 369 nesting "type length value" (tlv's) within the field. Each type is 370 then a focus for the private use option. More recently URIs have 371 been used to point to a source of authority. This allows an 372 organization to organize an abundance of information about their 373 namespaces. 375 5. Examples of Successful Private Use Options 377 This section contains a review of RFCs that allow the use of private 378 use options. There seem to be three ways to address the namespace: 379 via a global origin, via a truncated numerical origin, and via a 380 namespace based upon a domain name. 382 5.1. Private Enterprise Number 384 Rather than using the entire SMI, protocol engineers started using 385 just the Private Enterprise Number [IANApen]. This reduces the 386 length of the identifier but continues to provide an identifier 387 through a globally unique namespace. This section provides examples 388 of how the PEN has been used to provide private use options. 390 5.1.1. SNMP 392 Likely, the first private use option was defined in the Structure and 393 Identification of Management Information for TCP/IP-based Internets 394 [RFC1155] which was first used in A Simple Network Management 395 Protocol [RFC1067] (SNMP). The structure of management information 396 (SMI) has been updated and is currently defined as the Structure of 397 Management Information Version 2 (SMIv2) [RFC2578]. 399 SMI is a well described tree of OBJECT IDENTIFIERs (OIDs). OIDs have 400 an origin and a path for defined object identifiers which this 401 document describes as standard options. It also allows for 402 experimental and vendor specific object identifiers, which are 403 described as private use options in this document. The IANA 404 maintains a registry of these Network Management Parameters 405 [IANAsmi]. 407 The Internet subtree of experimental OBJECT IDENTIFIERs starts with 408 the prefix: 1.3.6.1.3., and the Internet subtree of private 409 enterprise OBJECT IDENTIFIERs starts with the prefix: 1.3.6.1.4.1. 410 This is followed by a Private Enterprise Number [IANApen] (PEN) and 411 then the objects defined by that enterprise. 413 The globally unique origin in SNMP (Section 5.1.1) is the 414 International Standards Organization [ISO] which is accredited by the 415 United Nations to maintain this structure. However, the namespace 416 resolves to the PEN (Section 5.1). 418 After the vendor identifier (the PEN) in the management information 419 base (MIB), a vendor can create many different trees to identify 420 objects. This may result in a very large number of OBJECT 421 IDENTIFIERs; each of which is an identifier of the namespace 422 described in this document. Each of these are uniquely identified by 423 the vendor and do not require registration with any coordinating 424 authority. 426 The last part of each OBJECT IDENTIFIER is the value corresponding to 427 the focus, which is known as the varbind. In a GetRequest the server 428 fills this field with a "0" and the client responds by replacing the 429 "0" with the actual value. Since this field is defined by the 430 vendor, it may actually be a concatenation of values. In a 431 SetRequest transmitted to the receiver, this is the last field. 433 In this, each OBJECT IDENTIFIER contains a globally unique origin 434 which is ISO, a focus which is the OBJECT IDENTIFIER down to the last 435 field, and a value which is the last field in the SetRequest, and the 436 last field in the response to a GetRequest. 438 Specific codes, known as error-indexes, are used to indicate when a 439 request cannot be processed because a device does not understand a 440 request. 442 While this is very practical for SNMP, fully qualified OIDs are not 443 always well suited to be used as an indicator for private use 444 options. In many other uses, the source of authority has been 445 truncated to just the PEN (Section 5.1). 447 5.1.2. RADIUS 449 The Remote Authentication Dial In User Service (RADIUS) [RFC2058] 450 specification documented how to use just the PEN (without the rest of 451 the SMI path to the root) to allow "vendors" to articulate their own 452 options. In that document, these are called Vendor-Specific 453 Attributes (VSA). 455 The updated RADIUS document, [RFC2865], gives guidance for using the 456 VSA. 458 o Servers not equipped to interpret the vendor-specific information 459 sent by a client MUST ignore it (although it may be reported). 461 o Clients which do not receive desired vendor-specific information 462 SHOULD make an attempt to operate without it, although they may do 463 so (and report they are doing so) in a degraded mode. 465 o The Attribute-Specific field is dependent on the vendor's 466 definition of that attribute. 468 o It SHOULD be encoded as a sequence of vendor type / vendor length 469 / value fields. 471 o Multiple subattributes MAY be encoded within a single Vendor- 472 Specific Attribute, although they do not have to be. 474 There are many attributes defined in RADIUS [RFC2058] which may be 475 considered to be standard options. Each of these attributes is 476 specified within a "type length value" (tlv) container. For this 477 protocol, the attribute "type" is a specific numerical value which 478 differentiates it from other attributes. As an example, the User- 479 Name (type 1) and User-Password (type 2) may be considered to be 480 standard options as they are well defined within the specification. 482 Type 26 denotes the Vendor Specified Attribute. It is "available to 483 allow vendors to support their own extended Attributes not suitable 484 for general usage". The PEN starts the "value" which should then 485 include a subsequent nested tlv so the vendor may define and 486 enumerate their own options within that field. 488 As noted above, the globally unique origin for RADIUS [RFC2865] is 489 the PEN. The remainder of the Attribute field after the PEN is 490 deliberately undefined in the specification. It is however suggested 491 that the field contain embedded tlv's. This is again very practical. 492 Each vendor may then have conflicting "types" (e.g. "1") which would 493 be disambiguated by the origin. For example {PEN="N", type="1"} is 494 different from {PEN="M", type="1"}. Since there is nothing to 495 prevent vendors from registering multiple PENs, each vendor may have 496 a plethora of {type="1"}. However, that is actually not needed since 497 the focus may be extended by enumerating multiple types. For 498 example, the vendor attribute may contain {PEN="M", type="1"(value), 499 type="2"(value), type="3"(value)}. 501 The values for each type are bounded by the length of the attribute. 502 Since the entire vendor attribute is defined by the vendor, the 503 values may be human readable or not. Since the protocol tends to be 504 machine-to-machine, it is likely that the values will not be human 505 readable. In some cases, it is feasible that a value has no length. 506 In that case, the transmission of the type alone, would be a signal 507 of some sort to the receiver. 509 5.1.3. Mobile IP 511 Mobile IP Vendor Specific Extensions [RFC3115] defines two extensions 512 that can be used for making organization specific extensions by 513 vendors/organizations for their own specific purposes for Mobile IP 514 [RFC2002]. Mobile IP has been revised several times and is currently 515 specified in IP Mobility Support for IPv4, Revised [RFC5944]. 517 In that specification, two tlv's have been defined to contain private 518 use options. These are collectively called Vendor/Organization 519 Specific Extensions (VSE). 521 o When the Critical Vendor/Organization Specific Extension (CVSE) is 522 encountered but not recognized, the message containing the 523 extension MUST be silently discarded. 525 o When a Normal Vendor/Organization Specific Extension (NVSE) is 526 encountered but not recognized, the extension SHOULD be ignored, 527 but the rest of the Extensions and message data MUST still be 528 processed. 530 Having two VSEs of this nature for private use options is consistent 531 with the original Mobile IP specification [RFC2002] which states: 533 When an Extension numbered in either of these sets within the 534 range 0 through 127 is encountered but not recognized, the message 535 containing that Extension MUST be silently discarded. When an 536 Extension numbered in the range 128 through 255 is encountered 537 which is not recognized, that particular Extension is ignored, but 538 the rest of the Extensions and message data MUST still be 539 processed. 541 The structure of the origin, type, and value of the CVSEs and NVSEs 542 for Mobile IP [RFC3115] may be used in a manner very similar to that 543 of RADIUS. The PEN is the origin and types and values may be stacked 544 within the field following that. 546 It should be noted that this does not have to be the case. 547 Specifying CVSEs and NVSEs in various packets can give a vendor 548 another dimension in processing these private use fields. If a 549 vendor placed all CVSEs in a single packet, and the receiver did not 550 understand any one of them, the entire packet must be discarded. 551 However, if the vendor places individual CVSEs in separate packets, 552 only CVSEs that are not understood by the receiver will be discarded. 554 Similarly, a vendor may choose to not stack NVSEs so that a receiver 555 won't discard the entire cluster of NVSEs if a single one is not 556 understood. 558 The values are constrained by the length of the types or subtypes. 560 5.1.4. DHCP 562 The introduction to Vendor-Identifying Vendor Options for Dynamic 563 Host Configuration Protocol version 4 (DHCPv4) [RFC3925] states: 565 The DHCP protocol for IPv4, [RFC2131], defines options that allow 566 a client to indicate its vendor type (option 60), and the DHCP 567 client and server to exchange vendor-specific information (option 568 43) [RFC2132]. Although there is no prohibition against passing 569 multiple copies of these options in a single packet, doing so 570 would introduce ambiguity of interpretation, particularly if 571 conveying vendor-specific information for multiple vendors. 573 This meant that Dynamic Host Configuration Protocol [RFC2131] 574 specified that there was one instance of the vendor type, and the 575 receiver used that namespace to set the scope for the fields in the 576 vendor-specific information option. This version of DHCP did not 577 allow for multiple origins; only a single origin was permitted and 578 the types were to be defined subsequent to that. Evidently this was 579 found to be unworkable when different vendors needed to expand 580 private use options in the protocol. 582 This situation was resolved with the publication of Vendor- 583 Identifying Vendor Options for Dynamic Host Configuration Protocol 584 version 4 (DHCPv4) [RFC3925] which states: 586 The Dynamic Host Configuration Protocol (DHCP) options for Vendor 587 Class and Vendor-Specific Information can be limiting or ambiguous 588 when a DHCP client represents multiple vendors. 590 That specification ([RFC3925]) then used the PEN [IANApen] to define 591 a unique namespace for private use options in this protocol. Similar 592 to other protocols of this era, tlv containers were used. 594 When this protocol was updated to conform to the requirements of 595 IPv6, the PEN was again used as the way to identify the origin of the 596 private use option. 598 5.1.5. Syslog 600 The Syslog Protocol [RFC5424] also uses the PEN to uniquely qualify 601 the namespace for a private use option. Standard options do not 602 contain the "@" character. Private use options must have the PEN 603 following the "@" character. This allows a vendor or experimenter to 604 have overlapping namespaces which the PEN will then uniquely 605 identify. For example the standard option of tzKnown may only have 606 associated values of "0" and "1". However tzKnown@32473 may have any 607 value assigned to it by the owner of enterprise number 32473. 609 Syslog transport receivers are supposed to accept all correctly 610 formatted Syslog messages. Unlike RADIUS, the receiving Syslog 611 application does not have to have immediate knowledge of all variable 612 options to continue operations. If a private use option is not 613 immediately known to the receiving application, it may still store 614 the message and an Operator or Administrator may look it up at a 615 later time if they are really interested. 617 The Syslog protocol [RFC5424] uses the PEN as the origin and allows 618 for the focus of the private use option to be fully defined by the 619 vendor within the structured data. Specifically, a vendor may define 620 a "type" of private use option by concatenating it with the PEN by 621 using the @ character. Within the bounds of the structured data, 622 multiple elements may be used that have identifiers and values. 624 5.2. Domain Name Strings 626 An alternative to using numerical indicators is to use textual 627 strings. Again, the goal for using these strings is to disambiguate 628 the identifiers and allow freedom of expression by the vendors and 629 experimenters using them. 631 5.2.1. Secure Shell 633 The Secure Shell (SSH) Protocol Architecture [RFC4251] uses character 634 strings rather than PENs. Similar to Syslog, but actually predating 635 it, standard options must not have the "@" character in them. 636 Private use options will have an origin identifier preceding an "@" 637 character followed by a namespace field. For example, in The Secure 638 Shell (SSH) Connection Protocol [RFC4254] SSH channels may be opened 639 by specifying a channel type when sending the SSH_MSG_CHANNEL_OPEN 640 message. Standard options for the channel type include "session" and 641 "x11". A private use option for a channel type could be 642 "example_session@example.com". 644 Obviously, these character strings are domain names [RFC1034] 645 [RFC1035]. This is specified in The Secure Shell (SSH) Protocol 646 Architecture [RFC4251]. Generally, the guidance given is that if a 647 private use option of this nature is not understood it is to convey 648 an error code to its peer. 650 In the SSH protocol [RFC4250], the origin is a domain name and the 651 focus of the option is dependent upon context. For example, 652 ourcipher-cbc@example.com can only be used when negotiating ciphers, 653 while example_session@example.com can only be used when negotiating 654 channel types, per the examples in [RFC4250]. 656 5.3. URN-based Namespaces 658 Uniform Resource Names (URNs) have also been used to convey options. 659 They are very flexible 661 (Need to add a lot here.) Uniform Resource Names (URN) Namespace 662 Definition Mechanisms [RFC3406] An IETF URN Sub-namespace for 663 Registered Protocol Parameters [RFC3555] The IETF XML Registry 664 [RFC3688] Extensible Provisioning Protocol (EPP) [RFC5730] Extensible 665 Provisioning Protocol (EPP) Host Mapping [RFC5732] Namespaces in XML 666 1.0 (Third Edition) [W3C.REC-xml-names-20091208] 668 5.3.1. YANG and NETCONF 670 YANG - A Data Modeling Language for the Network Configuration 671 Protocol (NETCONF) [RFC6020] and Network Configuration Protocol 672 (NETCONF) [RFC6241] use URIs to indicate private use namespaces. The 673 following is given as an example of a YANG and NETCONF configuration. 675 module my-config { 676 namespace "http://example.com/schema/config"; 677 prefix "co"; 679 container system { ... } 680 container routing { ... } 681 } 683 That example could be encoded in NETCONF as the following. 685 688 689 690 691 692 This eternal association 693 694 695 696 697 698 699 700 701 703 Section 8.3 of YANG [RFC6020] describes the parsing of the YANG 704 payload. It contains a good deal of information about how to process 705 elements or values that are not recognized. 707 Similarly, NETCONF [RFC6241] contains much information about 708 processing requests that cannot be completed because elements or 709 values are not recognized. 711 Both YANG [RFC6020] and NETCONF [RFC6241] use URIs to enumerate 712 private use options of a device. The use of this comes from XPATH 714 [W3C.REC-xpath-19991116]. 716 In both of these, the source of authority is the domain name in the 717 URI and the origin is the full URI path. Many private use options 718 may be described within YANG. From that, each private use option may 719 be populated in NETCONF. 721 The following is used to demonstrate this. First the YANG module is 722 shown, then a subset of the NETCONF is shown. 724 YANG module: 726 // Contents of "acme-system.yang" 727 module acme-system { 728 namespace "http://acme.example.com/system"; 729 prefix "acme"; 731 organization "ACME Inc."; 732 contact "joe@acme.example.com"; 733 description 734 "The module for entities implementing the ACME system."; 736 revision 2007-06-09 { 737 description "Initial revision."; 738 } 740 container system { 741 leaf host-name { 742 type string; 743 description "Hostname for this system"; 744 } 746 leaf-list domain-search { 747 type string; 748 description "List of domain names to search"; 749 } 751 container login { 752 leaf message { 753 type string; 754 description 755 "Message given at start of login session"; 756 } 758 list user { 759 key "name"; 760 leaf name { 761 type string; 762 } 763 leaf full-name { 764 type string; 765 } 766 leaf class { 767 type string; 768 } 769 } 770 } 771 } 772 } 774 NETCONF exchange: 776 777 778 Good morning 779 780 782 In this example, YANG describes the source of authority and focus for 783 the login message, and the NETCONF exchange populates that specific 784 value. 786 As noted above, both of these specifications have good descriptions 787 of actions to take if a namespace is not recognized. 789 6. Issues to Consider 791 This document is not an encouragement or recommendation to define 792 private use fields in IETF protocols. Rather, since private use 793 options are useful to the community and seem to be gaining 794 popularity, this document is an attempt to document the ways in which 795 they have been successful so others may benefit. 797 Private use options are a way to allow vendors, network operators, 798 and experimenters to convey dynamic information without going through 799 a rigorous process to register each variable. There is no "one size 800 fits all" mechanism. The use of a very specific and fixed format 801 works very well for RADIUS which requires speed in processing. On 802 the other hand, the open nature of the private use options in Syslog 803 are appropriate for that protocol where event messages need not be 804 fully parsed at the time of reception. 806 There seem to be four essential features to using a private use 807 option. 809 o One requirement is to have a definable way for the community to 810 ascertain the nature of all private use options. For example, 811 several vendors have published their RADIUS VSAs on web pages 812 which are easy to find. From that, anyone creating a new RADIUS 813 server would have access to, and be able to incorporate the 814 information available. 816 o Instructions are needed on how to deal with private use options 817 that are not understood by a receiver. In some cases, a receiver 818 may not need to understand the options immediately upon receipt as 819 in the case of Syslog. In other cases, the options are 820 immediately used and instructions must be clear on what to do if 821 the receiver cannot process them. It appears that Mobile IP has 822 the best thought-through instructions on this. 824 o Private use options must be extensible in a clearly designed way. 825 RADIUS suggests that the string containing the option be another 826 tlv. This allows a vendor to define multiple private use options 827 within their own namespace field. These are becoming known as 828 subattributes. This appears to be working in practice and it may 829 be assumed that this has become a de facto rule for RADIUS. 831 o In most cases, a unique option (both standard and private use) 832 will only be used once within the context of an exchange. RADIUS 833 and DHCP either state or strongly imply this. However, while it 834 is not explicitly discussed, there is nothing to prevent this 835 within Syslog. Some guidance should be given about this in 836 describing private use options in protocols. 838 Clear documentation in full and open standards is needed to achieve 839 uniformity and interoperability in these features. Obviously 840 implementers will need to adhere closely to these standards for 841 complete interoperability. 843 Finally, the usage of any private use values on the wire before any 844 namespace is properly reserved with the IANA is entirely inadvisable. 846 6.1. Value of the Option 848 The value of each private use option must be well defined and 849 bounded. It is advisable that it be extensible to accomodate future 850 requirements. 852 Generally speaking, values of private use options should follow the 853 same guidance given for standard options. 855 6.2. Guidance on Incomplete Understanding 857 Within the protocol, an understanding needs to be established between 858 the transmitter and receiver about what to do if the receiver does 859 not understand a namespace. Some protocols have defined that a 860 receiver will silently discard packets that contain private use 861 options they do not understand. Other protocols have defined that 862 they will only discard the private use option rather than the entire 863 packet. While other protocols have no need for the receiver to have 864 any understanding of any private use options when it receives them. 865 Each of these behaviors is represented in the examples in this 866 document. 868 Regardless of whether or not this understanding is established, the 869 receiver of any protocol must have a defined path of action to follow 870 when receiving anything that it may not understand. 872 7. Authors Notes 874 This section will be removed prior to publication. 876 This is version -11. The day job is keeping me busy. But I'm 877 getting close to addressing my procrastination issues. ..just you 878 wait and see. 880 8. Security Considerations 882 This document reviews ways that options are being used in various 883 protocols. As such, there are no security considerations inherent in 884 this document. 886 Readers and implementers should be aware of the context of 887 implementing options in their own protocols. 889 9. IANA Considerations 891 This document does not propose a standard and does not require the 892 IANA to do anything. 894 10. Acknowledgments 896 The idea for documenting this came from questions asked in the SIP- 897 CLF Working Group and the author is grateful for the discussion 898 around this topic. 900 The following people have contributed to this document. Listing 901 their names here does not mean that they agree with or endorse the 902 document, but that they have contributed to its substance. 904 David Harrington, Dan Romascanu, Bert Wijnen, Ralph Droms, Juergen 905 Schoenwalder, Nevil Brownlee, Klaas Wierenga, and Brian Carpenter. 907 11. References 909 [IANAtcp] Internet Assigned Numbers Authority, "IANA Transmission 910 Control Protocol (TCP) Parameters, TCP Option Kind 911 Numbers", 2011, . 914 [IANAftp] Internet Assigned Numbers Authority, "IANA FTP Commands 915 and Extensions", 2010, . 918 [IANAslg] Internet Assigned Numbers Authority, "IANA syslog 919 Parameter", 2010, 920 . 922 [IANAsmi] Internet Assigned Numbers Authority, "Network Management 923 Parameters", 2011, 924 . 926 [IANApen] Internet Assigned Numbers Authority, "IANA PRIVATE 927 ENTERPRISE NUMBERS", 2011, 928 . 930 [wpProt] Wikipedia - the Free Dictionary, "Wikipedia entry for 931 communication protocol", 2011, 932 . 934 [ISO] International Standards Organization, "International 935 Standards Organization", 2011, . 937 [ICANN] Internet Corporation for Assigned Names and Numbers, 938 "Internet Corporation for Assigned Names and Numbers", 939 2011, . 941 [RFC0761] Postel, J., "DoD standard Transmission Control Protocol", 942 RFC 761, January 1980. 944 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 945 September 1981. 947 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 948 text messages", STD 11, RFC 822, August 1982. 950 [RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, 951 RFC 868, May 1983. 953 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 954 STD 9, RFC 959, October 1985. 956 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 957 STD 13, RFC 1034, November 1987. 959 [RFC1035] Mockapetris, P., "Domain names - implementation and 960 specification", STD 13, RFC 1035, November 1987. 962 [RFC1067] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 963 "Simple Network Management Protocol", RFC 1067, 964 August 1988. 966 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification 967 of management information for TCP/IP-based internets", 968 STD 16, RFC 1155, May 1990. 970 [RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, 971 October 1996. 973 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 974 RFC 2131, March 1997. 976 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 977 Extensions", RFC 2132, March 1997. 979 [RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens, 980 "Remote Authentication Dial In User Service (RADIUS)", 981 RFC 2058, January 1997. 983 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 984 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 985 October 1998. 987 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 988 Schoenwaelder, Ed., "Structure of Management Information 989 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 991 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 992 "Remote Authentication Dial In User Service (RADIUS)", 993 RFC 2865, June 2000. 995 [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/ 996 Organization-Specific Extensions", RFC 3115, April 2001. 998 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 999 "Uniform Resource Names (URN) Namespace Definition 1000 Mechanisms", BCP 66, RFC 3406, October 2002. 1002 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1003 Payload Formats", RFC 3555, July 2003. 1005 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1006 January 2004. 1008 [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for 1009 Dynamic Host Configuration Protocol version 4 (DHCPv4)", 1010 RFC 3925, October 2004. 1012 [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) 1013 Protocol Assigned Numbers", RFC 4250, January 2006. 1015 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1016 Protocol Architecture", RFC 4251, January 2006. 1018 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1019 Connection Protocol", RFC 4254, January 2006. 1021 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1023 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1024 STD 69, RFC 5730, August 2009. 1026 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1027 Host Mapping", STD 69, RFC 5732, August 2009. 1029 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 1030 RFC 5944, November 2010. 1032 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1033 Network Configuration Protocol (NETCONF)", RFC 6020, 1034 October 2010. 1036 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1037 Bierman, "Network Configuration Protocol (NETCONF)", 1038 RFC 6241, June 2011. 1040 [W3C.REC-xpath-19991116] 1041 Clark, J. and S. DeRose, "XML Path Language (XPath) 1042 Version 1.0", World Wide Web Consortium 1043 Recommendation REC-xpath-19991116, November 1999, 1044 . 1046 [W3C.REC-xml-names-20091208] 1047 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 1048 Thompson, "Namespaces in XML 1.0 (Third Edition)", World 1049 Wide Web Consortium Recommendation REC-xml-names-20091208, 1050 December 2009, 1051 . 1053 Author's Address 1055 Chris Lonvick 1056 1307 Kent Oak Dr. 1057 Houston, Texas 77077 1058 US 1060 Email: lonvick.ietf@gmail.com