One document matched: draft-lonvick-private-tax-00.txt
Network Working Group C. Lonvick
Internet-Draft May 11, 2011
Intended status: Informational
Expires: November 12, 2011
A Taxonomy on Private Use Fields in Protocols
draft-lonvick-private-tax-00.txt
Abstract
The fields in protocols that are reserved for private use have been
purposefully unregulated. This document attempts to provide some
classifications for the way that private use fields have been used in
protocols developed in the IETF.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 12, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Lonvick Expires November 12, 2011 [Page 1]
Internet-Draft Private Use Fields May 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Origins of the Private Use Name Space . . . . . . . . . . . . 4
3. Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Examples of Successful Private Use Options . . . . . . . . . . 6
4.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Private Enterprise Number . . . . . . . . . . . . . . . . 7
4.2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 8
4.2.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.4. IPFIX . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.5. Syslog . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Character strings . . . . . . . . . . . . . . . . . . . . 10
5. Characteristics of Useful Private Use Options . . . . . . . . 10
5.1. Source of Authority . . . . . . . . . . . . . . . . . . . 11
5.2. Focus of the Name Space . . . . . . . . . . . . . . . . . 11
5.3. Value of the Option . . . . . . . . . . . . . . . . . . . 12
6. Issues to Consider . . . . . . . . . . . . . . . . . . . . . . 12
7. Authors Notes . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Lonvick Expires November 12, 2011 [Page 2]
Internet-Draft Private Use Fields May 2011
1. Introduction
Simply put, communications protocols are standardized ways for
computing entities to convey information. Within each communications
protocol, there must be standardized pieces of information that will
be communicated, and there may be non-standardized information that
can be communicated.
Time Protocol [RFC0868] is an example of a protocol that only conveys
standardized information. There is no way to add anything other than
what is specified in the document. On the other hand, DoD standard
Transmission Control Protocol [RFC0761] does have "options" but they
must be registered through the IANA [IANAtcp], which does not leave
any room for optional information supplied by equipment vendors,
network operators, or experimenters. Finally, Vendor-Identifying
Vendor Options for Dynamic Host Configuration Protocol version 4
(DHCPv4) [RFC3925] does allow for vendor specific options.
If a network operator wanted to add specific information to the Time
Protocol [RFC0868], they could modify the code of the senders and
receivers and run this within their own domain without any problems.
However, if an equipment vendor wanted to include information
specific to their equipment, they would have to ensure that all
senders and receivers within all network domains would either accept
the change in the protocol, or would not have problems with it. As a
final case, if several equipment vendors desired to add equipment-
specific information to this protocol, they would have to take great
care that only their own receivers would accept information from
their own transmitters. An extension to that would be that if one
equipment vendor would like to transmit or receive the same
information that another vendor is using.
For the case of TCP [RFC0761], standard options are expected; senders
may use them and receivers may be configured to act upon that
information, or to ignore it. If an experimenter wants to add an
option, they will have to create a new IETF RFC with the details, or
obtain approval from the IESG to have the IANA add to the registry
[IANAtcp]. Similarly, if equipment vendors Foo and Bar were to have
a need for a similar option within TCP, they would each have to go
through the process to add to the registry. On the other hand, if a
properly crafted multipurpose, private use option were to be
registered, such as in the case of multiple vendor instances within
Vendor-Identifying Vendor Options for Dynamic Host Configuration
Protocol version 4 (DHCPv4) [RFC3925] then vendors and experimenters
would each be able to use it for their own purposes as long as all
network participants can easily differentiate between the entities
using the option.
Lonvick Expires November 12, 2011 [Page 3]
Internet-Draft Private Use Fields May 2011
This document explores the various ways that protocols may allow
optional information using fields designated as "private use" to be
included in protocols, without disrupting the desired harmony of the
network. [RFC4735]
2. Origins of the Private Use Name Space
Guidelines for Writing an IANA Considerations Section in RFCs
[RFC2432] describes that values of specific name spaces may either be
registered with the IANA, or not. In most cases, there are well
defined values for name spaces. However, as the document explains,
not all name spaces require centralized administration.
In that document, it seems to be assumed that private use name spaces
will be domain specific and it will be up to the administrators of
any domain to avoid conflicts. The first example given about private
use name spaces refers to Dynamic Host Configuration Protocol
[RFC2131] and presumably DHCP Options and BOOTP Vendor Extensions
[RFC2132]. In this the example states that "site-specific options in
DHCP have significance only within a single site". As noted below
this became a problem that was rectified in a later revision of DHCP.
Later works identified a need to place a scope on private use name
spaces. The second example of private use name spaces in [RFC2432]
is from STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES
[RFC0822] which describes X- headers. Again, there is no effort made
to control the name space. It appears however that the users of X-
headers have self-organized; most consistently use features that are
universally useful and many have incorporated identifiers for useful
features that may overlap.
3. Nomenclature
In this document, the following words are defined to prevent
ambiguity. Some of these words have not been used in the referenced
works but their meanings can be ascertained.
o communications protocol - a formal description of digital message
formats and the rules for exchanging those messages in or between
computing systems and in telecommunications [wpProt]
o protocol frame - a defined container of fields used to convey
information in a communications protocol
o field - any defined container within a communications protocol
frame
Lonvick Expires November 12, 2011 [Page 4]
Internet-Draft Private Use Fields May 2011
o standard option - a field in a protocol frame that may only use
values that are strictly defined within a specification
o private use option - a field in a protocol frame that is reserved
for private or local use only name spaces
o name space - the set of possible values a field may contain; its
actual content may be a name, a number or another kind of value
Examples
o communications protocol - The File Transfer Protocol [RFC0959] is
an example of a communications protocol. It has well defined
fields and standard options. The Syslog Protocol [RFC5424] is
another example of a communications protocol. It has well defined
fields, standard options, and it also has private use options.
o protocol frame - An Internet Protocol packet [RFC0791] is
considered to be a protocol frame. In the case of The File
Transfer Protocol [RFC0959], an FTP message from the client to the
server within the Internet Protocol [RFC0791] containing an FTP
command is a protocol frame. In the case of The Syslog Protocol
[RFC5424], a message from the client to the server within the
Internet Protocol [RFC0791] containing a syslog message is also a
protocol frame.
o field - In the case of The File Transfer Protocol [RFC0959], a
command will be contained within a field. In the case of The
Syslog Protocol [RFC5424], the HOSTNAME is a field.
o standard option - In the case of The File Transfer Protocol
[RFC0959], an FTP command, such as CDUP and QUIT, is a standard
option. The reason that a command is a standard option is that
only the values listed by the IANA in the registry [IANAftp] may
be used. The standard options are not limited to the values
defined in the original RFC, but also include any additions to the
registry. In the case of The Syslog Protocol [RFC5424], an SD-ID
may be a standard option. The example given in Section 7.1.4 of
[RFC5424] of
[timeQuality tzKnown="0" isSynced="0"]
is a standard option because all of the fields are listed in the
document and in the IANA registry [IANAslg].
o private use option - In the case of The Syslog Protocol, an SD-ID
may be a private use option. Example 3 given in Section 6.5
contains a private use option.
Lonvick Expires November 12, 2011 [Page 5]
Internet-Draft Private Use Fields May 2011
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com
evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
"Application" eventID="1011"] BOMAn application
event log entry...
Specifically, the SD-ID starting with "[exampleSDID@32473 ..." is
not a specifically defined option in the RFC, nor is it registered
in the IANA registry [IANAslg]. It is a way for an equipment
vendor to insert their specific information without having to
register anything. In this case if the receiver knows the format
of that SD-ID then it can immediately interpret its meaning.
However, if it does not know how to interpret that SD-ID, it can
still log the message and an Operator or Administrator can look up
its meaning at a later time.
o name space - In the same Example 3 from Section 6.5 of The Syslog
Protocol [RFC5424], "exampleSDID@32473" provides the name space so
the context of the rest of the SD-ID may be interpreted.
Specifically the Private Enterprise Number [IANApen] (PEN) is used
to associate the option with a private enterprise, and the text
before the "@" identifies the option defined within that private
enterprise.
4. Examples of Successful Private Use Options
This section contains a review of RFCs that allow the use of private
use options. There seem to be three ways to address the name space:
via a global origin, via a truncated numerical origin, and via a
namespace based upon the domain name.
4.1. SNMP
Likely, the first private use option was defined in the Structure and
Identification of Management Information for TCP/IP-based Internets
[RFC1155] which was first used in A Simple Network Management
Protocol [RFC1067] (SNMP). The structure of management information
(SMI) has been updated and is currently defined as the Structure of
Management Information Version 2 (SMIv2) [RFC2578].
SMI is a well described tree of OBJECT IDENTIFIERs. It has an origin
and a path for defined object identifiers which this document
describes as standard options. It also allows for experimental and
vendor specific object identifiers, which are described as private
use options in this document. The IANA maintains a registry of these
Network Management Parameters [IANAsmi].
The Internet subtree of experimental OBJECT IDENTIFIERs starts with
Lonvick Expires November 12, 2011 [Page 6]
Internet-Draft Private Use Fields May 2011
the prefix: 1.3.6.1.3., and the Internet subtree of private
enterprise OBJECT IDENTIFIERs starts with the prefix: 1.3.6.1.4.1.
This is followed by a Private Enterprise Number [IANApen] (PEN) and
then the OBJECT IDENTIFIERs defined by that enterprise.
While this is very practical and practicable for SNMP, fully
qualified SMIs do not lend themselves well for other uses as a
generic private use option.
4.2. Private Enterprise Number
Rather than using the entire SMI, protocol engineers started using
just the Private Enterprise Number [IANApen]. This reduces the
length of the identifier but continues to provide an identifier
through a globally unique name space. This subsection provides
examples of how the PEN has been used to provide private use options.
4.2.1. RADIUS
The Remote Authentication Dial In User Service (RADIUS) [RFC2058]
specification documented how to use just the PEN (without the rest of
the SMI path to the root) to allow "vendors" to articulate their own
options. In this document, these are called Vendor-Specific
Attributes (VSA).
The updated RADIUS document, [RFC2865], gives guidance for using the
VSA.
o Servers not equipped to interpret the vendor-specific information
sent by a client MUST ignore it (although it may be reported).
o Clients which do not receive desired vendor-specific information
SHOULD make an attempt to operate without it, although they may do
so (and report they are doing so) in a degraded mode.
o The Attribute-Specific field is dependent on the vendor's
definition of that attribute.
o It SHOULD be encoded as a sequence of vendor type / vendor length
/ value fields.
o Multiple subattributes MAY be encoded within a single Vendor-
Specific Attribute, although they do not have to be.
There are many attributes defined in RADIUS [RFC2058] which may be
considered to be standard variables. Each of these attributes are
specified within a "type length value" (tlv) container. For this
protocol, the VSA "type" is a specific numerical value which
Lonvick Expires November 12, 2011 [Page 7]
Internet-Draft Private Use Fields May 2011
separates it from other attributes. Type 26 (decimal) denotes a VSA,
and the PEN starts the "value" which should then include a subsequent
nested tlv so the vendor may enumerate their own options within the
field.
4.2.2. Mobile IP
Mobile IP Vendor Specific Extensions [RFC3115] defines two extensions
that can be used for making organization specific extensions by
vendors/organizations for their own specific purposes for Mobile IP
[RFC2002]. Mobile IP has been revised several times and is currently
specified in IP Mobility Support for IPv4, Revised [RFC5944].
In this specification, two tlv's have been defined to contain private
use options. These are called Vendor/Organization Specific
Extensions (VSE).
o When the Critical Vendor/Organization Specific Extension (CVSE) is
encountered but not recognized, the message containing the
extension MUST be silently discarded.
o When a Normal Vendor/Organization Specific Extension (NVSE) is
encountered but not recognized, the extension SHOULD be ignored,
but the rest of the Extensions and message data MUST still be
processed.
Having two VSEs of this nature for private use options is consistent
with the original Mobile IP specification [RFC2002] which states:
When an Extension numbered in either of these sets within the
range 0 through 127 is encountered but not recognized, the message
containing that Extension MUST be silently discarded. When an
Extension numbered in the range 128 through 255 is encountered
which is not recognized, that particular Extension is ignored, but
the rest of the Extensions and message data MUST still be
processed.
4.2.3. DHCP
The introduction to Vendor-Identifying Vendor Options for Dynamic
Host Configuration Protocol version 4 (DHCPv4) [RFC3925] states:
The DHCP protocol for IPv4, [RFC2131], defines options that allow
a client to indicate its vendor type (option 60), and the DHCP
client and server to exchange vendor-specific information (option
43) [RFC2132]. Although there is no prohibition against passing
multiple copies of these options in a single packet, doing so
would introduce ambiguity of interpretation, particularly if
Lonvick Expires November 12, 2011 [Page 8]
Internet-Draft Private Use Fields May 2011
conveying vendor-specific information for multiple vendors.
This meant that Dynamic Host Configuration Protocol [RFC2131]
specified that there was one instance of the vendor type, and the
receiver used that name space to set the scope for the fields in the
vendor-specific information option.
This situation was resolved with the publication of Vendor-
Identifying Vendor Options for Dynamic Host Configuration Protocol
version 4 (DHCPv4) [RFC3925] which states:
The Dynamic Host Configuration Protocol (DHCP) options for Vendor
Class and Vendor-Specific Information can be limiting or ambiguous
when a DHCP client represents multiple vendors.
That specification ([RFC3925]) then used the PEN [IANApen] to defined
a unique name space for private use options in this protocol.
Similar to other protocols of this era, tlv containers were used.
4.2.4. IPFIX
Recording IP flow information is the subject of the Specification of
the IP Flow Information Export (IPFIX) Protocol for the Exchange of
IP Traffic Flow Information [RFC5101]. Since flows may be created
and concluded very quickly, processing speed is essential to this
protocol. As such, it is a protocol based upon binary fields that
can be interpreted quickly.
Even though the protocol is binary oriented rather than character
oriented, it still uses the PEN to identify the origin of the private
use option. All options are identified as Information Elements in
this specification. The first field of each Information Element is a
single bit identified as the Enterprise bit, which is defined as
follows:
Enterprise bit. This is the first bit of the Field Specifier. If
this bit is zero, the Information Element Identifier identifies an
IETF-specified Information Element, and the four-octet Enterprise
Number field MUST NOT be present. If this bit is one, the
Information Element identifier identifies an enterprise-specific
Information Element, and the Enterprise Number filed MUST be
present.
The specification goes on to say:
The Collecting Process MUST note the Information Element
identifier of any Information Element that it does not understand
and MAY discard that Information Element from the Flow Record.
Lonvick Expires November 12, 2011 [Page 9]
Internet-Draft Private Use Fields May 2011
4.2.5. Syslog
The Syslog Protocol [RFC5424] also uses the PEN to uniquely qualify
the name space for a private use option. Standard options do not
contain the "@" character. Private use options must have the PEN
following the "@" character. This allows a vendor or experimenter to
have overlapping name spaces which the PEN will then uniquely
identify. For example a standard option is tzKnown which may only
have associated values of "0" and "1". However tzKnown@32473 may
have any value assigned to it by the owner of enterprise number
32473.
Syslog transport receivers are supposed to accept all correctly
formatted Syslog messages. Unlike RADIUS, the receiving Syslog
application does not have to have immediate knowledge of all variable
options to continue operations. If a private use option is not
immediately known to the receiving application, it may still store
the message and an Operator or Administrator may look it up at a
later time if they are really interested.
4.3. Character strings
The Secure Shell (SSH) Protocol Architecture [RFC4251] uses character
strings rather than PENs. Similar to Syslog, but actually predating
it, standard options must not have the "@" character in them.
Private use options will have an origin identifier preceding an "@"
character followed by a name space field. For example, in The Secure
Shell (SSH) Connection Protocol [RFC4254] SSH channels may be opened
by specifying a channel type when sending the SSH_MSG_CHANNEL_OPEN
message. Standard options for the channel type include "session" and
"x11". A private use option for a channel type could be
"example_session@example.com".
Obviously, these character strings are domain names [RFC1034]
[RFC1035]. This is specified in The Secure Shell (SSH) Protocol
Architecture [RFC4251]. Generally, the guidance given is that if a
private use option of this nature is not understood it is to convey
to its peer an error code.
5. Characteristics of Useful Private Use Options
This section summarizes the observed characteristics of private use
options that are successful and deployed.
There seem to be three characteristics of successful private use
options.
Lonvick Expires November 12, 2011 [Page 10]
Internet-Draft Private Use Fields May 2011
5.1. Source of Authority
A private use option requires a path to an origin that has the
authority to create and maintain the option. As shown above, this
referent should be unique, and not dependent upon local
interpretation.
In the case of SNMP (Section 4.1), the globally unique origin is the
International Standards Organization [ISO] which is accredited by the
United Nations to maintain this structure. However, the namespace
resolves to the PEN (Section 4.2) which does not seem to be globally
unique.
The PEN (Section 4.2) is sourced by the Internet Assigned Numbers
Authority (IANA). While there seems to be no reports of problems
using PENs, PENs do not seem to be unique. It appears that some
private enterprises have registered multiple PENs, and that there are
some private enterprises whose PENs are no longer serviceable, mostly
because they have been acquired by other companies, or they have gone
out of business.
Domain names have similar problems as they can be more ephemeral than
eternal. The top level domains are maintained by the Internet
Corporation for Assigned Names and Numbers [ICANN] however the
specific names are assigned much more locally. Unlike PENs that
become unserviceable when their owning organization goes out of
business, domain names that fall into disuse may be acquired and used
by entirely different organizations. Again however, like the use of
PENs there have not been any problems reported from this.
5.2. Focus of the Name Space
Once the source of authority is established, an actual option, or
options, must be specified.
In the case of SNMP (Section 4.1), after the vendor identifier (the
PEN) in the management information base (MIB) a vendor can create
many different trees to identify objects. This may result in a very
large number of object identifiers which are called private use
options in this document.
The PEN (Section 4.2) can used in myriad ways.
For RADIUS (Section 4.2.1), the PEN is used as the first field in
the resolution of an option. The recommendation is that the
vendor then create a tlv, or multiple tlv's, within the option
field. That would allow a vendor to specify multiple values, each
with a different focus, within the same option field by
Lonvick Expires November 12, 2011 [Page 11]
Internet-Draft Private Use Fields May 2011
concatenating tlv's.
Mobile IP (Section 4.2.2) allows that a vendor may have multiple
private use options within a protocol frame. Each will start as
any other option, will include the PEN as the source of authority
to specify the option, and will then have a "type" field to denote
the focus of the option. The "type" will either be the Vendor-
NVSE-Type or the Vendor-CVSE-Type. Regardless, there is only one
"value" allowed in each option field. A vendor wishing to include
multiple private use options would then have to create multiple
options, each with a different focus, within a protocol frame.
As it is used today, DHCP (Section 4.2.3) only allows a single
instance of the PEN as a vendor option identifier in a protocol
frame. Within the option, sub-option codes are to be used as the
start of one or more tlv's which will allow a vendor to specify as
many private use options as they need. This is similar to RADIUS.
In the IPFIX (Section 4.2.4) template, private use options are
described within Information Elements. These may have multiple
values described through Information Element Identifiers, which
makes this quite extensible.
The Syslog protocol (Section 4.2.5) allows for the focus of the
private use option to be fully defined by the vendor within the
structured data. Specifically, a vendor may define a "type" of
private use option by concatenating it with the PEN by using the @
character. Within the bounds of the structured data, multiple
elements may be used that have identifiers and values.
Finally, in the SSH protocol (Section 4.3), the focus of the option
is dependent upon context. For example, ourcipher-cbcexample.com can
only be used when negotiating ciphers, while
example_sessionexample.com can only be used when negotiating channel
types per the examples in [RFC4250].
5.3. Value of the Option
The value of each private use option must be extensible but bounded.
(I'd write more but see Section 7.)
6. Issues to Consider
Private use options are useful to the community and are gaining
popularity. This is a way to allow vendors, network operators, and
experimenters to convey dynamic information without going through a
rigorous process to register each variable.
Lonvick Expires November 12, 2011 [Page 12]
Internet-Draft Private Use Fields May 2011
There is no "one size fits all" mechanism. The use of a very
specific and fixed format works very well for IPFIX which requires
speed in processing. On the other hand, the open nature of the
private use options in Syslog is appropriate for that protocol.
The structure of the SMI is uniform and globally unique, but the pen
is not up to date. It appears that the people listed as the contacts
for some of the organizations have moved on, and that some of the
organizations have either been acquired by other organizations or
have gone out of business. It also appears that some organizations
have registered multiple PENs. The author is really not sure why
they would need to do that so any clue here would be appreciated.
Using the PEN with an extension or even with an entire SMI may be
constrained to fit nicely into a binary oriented protocol that has
strict field lengths. Using domain names, as SSH does, may also be
fit within binary protocols but since domain name lengths vary, tlv's
or some other mechanism may need to be used to establish the
boundaries of fields.
RADIUS dictates what to do if a private use option is not understood
by a receiver. Mobile IP Vendor Specific Extensions [RFC3115] builds
on that by letting a receiver know if it must process the entire
packet containing a private use option, or if it may ignore a private
use option that it doesn't understand but yet continue processing the
rest of the packet. On the other hand, Syslog does not require a
receiver to understand anything about any private use options. It is
expected that receivers that do understand the private use options
will be able to take actions more appropriately based on the
information they receiver.
From that, it is important to define in protocol specifications what
actions to take when a receiver receives a frame with a private use
options.
7. Authors Notes
This section will be removed prior to publication.
Now that I've written it, I'm thinking that I should pivot the
"characteristics" section. I think it would be easier to explain
source/focus/value on a per protocol basis rather than each with
examples within each protocol. That will be done in -01. :-)
I need to revise the Issues section. I'd like to write a lot more
description there but I want this version out the door first.
Lonvick Expires November 12, 2011 [Page 13]
Internet-Draft Private Use Fields May 2011
8. Security Considerations
This document reviews ways that options are being used in various
protocols. As such, there are no security considerations inherent in
this document.
Readers and implementers should be aware of the context of
implementing options in their own protocols.
9. IANA Considerations
This document does not propose a standard and does not require the
IANA to do anything.
10. Acknowledgments
The idea for documenting this came from questions asked in the SIP-
CLF Working Group and the author is grateful for the discussion
around this topic.
The following people have contributed to this document. Listing
their names here does not mean that they endorse the document, but
that they have contributed to its substance.
David Harrington, Dan Romascanu and Bert Wijnen.
11. References
[IANAtcp] Internet Assigned Numbers Authority, "IANA Transmission
Control Protocol (TCP) Parameters, TCP Option Kind
Numbers", 2011, <http://www.iana.org/assignments/
tcp-parameters/tcp-parameters.txt>.
[IANAftp] Internet Assigned Numbers Authority, "IANA FTP Commands
and Extensions", 2010, <http://www.iana.org/assignments/
ftp-commands-extensions/ftp-commands-extensions.txt>.
[IANAslg] Internet Assigned Numbers Authority, "IANA syslog
Parameter", 2010,
<http://www.iana.org/assignments/syslog-parameters>.
[IANAsmi] Internet Assigned Numbers Authority, "Network Management
Parameters", 2011,
<http://www.iana.org/assignments/smi-numbers>.
Lonvick Expires November 12, 2011 [Page 14]
Internet-Draft Private Use Fields May 2011
[IANApen] Internet Assigned Numbers Authority, "IANA PRIVATE
ENTERPRISE NUMBERS", 2011,
<http://www.iana.org/assignments/enterprise-numbers>.
[wpProt] Wikipedia - the Free Dictionary, "Wikipedia entry for
communication protocol", 2011,
<http://en.wikipedia.org/wiki/Communications_protocol>.
[ISO] International Standards Organization, "International
Standards Organization", 2011, <http://www.iso.org>.
[ICANN] Internet Corporation for Assigned Names and Numbers,
"Internet Corporation for Assigned Names and Numbers",
2011, <http://www.icann.org>.
[RFC0761] Postel, J., "DoD standard Transmission Control Protocol",
RFC 761, January 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26,
RFC 868, May 1983.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1067] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol", RFC 1067,
August 1988.
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification
of management information for TCP/IP-based internets",
STD 16, RFC 1155, May 1990.
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002,
October 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
Lonvick Expires November 12, 2011 [Page 15]
Internet-Draft Private Use Fields May 2011
RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2058, January 1997.
[RFC2432] Dubray, K., "Terminology for IP Multicast Benchmarking",
RFC 2432, October 1998.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/
Organization-Specific Extensions", RFC 3115, April 2001.
[RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for
Dynamic Host Configuration Protocol version 4 (DHCPv4)",
RFC 3925, October 2004.
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Connection Protocol", RFC 4254, January 2006.
[RFC4735] Taylor, T., "Example Media Types for Use in
Documentation", RFC 4735, October 2006.
[RFC5101] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", RFC 5101, January 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for
Documentation Use", RFC 5612, August 2009.
Lonvick Expires November 12, 2011 [Page 16]
Internet-Draft Private Use Fields May 2011
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised",
RFC 5944, November 2010.
Author's Address
Chris Lonvick
213 El Rancho Grande
Kerrville, Texas 78028
US
Email: lonvick.ietf@gmail.com
Lonvick Expires November 12, 2011 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 04:24:23 |