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