< draft-narten-iana-experimental-allocations-04.txt   draft-narten-iana-experimental-allocations-05.txt >
INTERNET-DRAFT Thomas Narten INTERNET-DRAFT Thomas Narten
<draft-narten-iana-experimental-allocations-04.txt> IBM <draft-narten-iana-experimental-allocations-05.txt> IBM
October 7, 2003 November 12, 2003
Assigning Experimental and Testing Numbers Considered Useful Assigning Experimental and Testing Numbers Considered Useful
<draft-narten-iana-experimental-allocations-04.txt> <draft-narten-iana-experimental-allocations-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
experimentation purposes that implementers can use when testing experimentation purposes that implementers can use when testing
protocol extensions or other new features. This document reserves protocol extensions or other new features. This document reserves
some ranges of numbers for experimentation purposes in specific some ranges of numbers for experimentation purposes in specific
protocols where the need to support experimentation has been protocols where the need to support experimentation has been
identified. identified.
Contents Contents
Status of this Memo.......................................... 1 Status of this Memo.......................................... 1
1. Introduction............................................. 2 1. Introduction............................................. 2
1.1. Recommendation for Protocols........................ 4
2. IANA Considerations...................................... 4 2. IANA Considerations...................................... 5
2.1. IP Protocol Field................................... 4 2.1. IP Protocol Field................................... 5
2.2. Existing Name Spaces................................ 5
3. Security Considerations.................................. 5 3. Security Considerations.................................. 5
4. Acknowledgments.......................................... 5 4. Acknowledgments.......................................... 5
5. Normative References..................................... 5 5. Normative References..................................... 6
6. Informative References................................... 5 6. Informative References................................... 6
1. Introduction 1. Introduction
When experimenting with or extending protocols, it is often necessary When experimenting with or extending protocols, it is often necessary
to have a protocol number as part of the implementation [IANA- to have a protocol number as part of the implementation [IANA-
CONSIDERATIONS]. For example, to develop a protocol that runs CONSIDERATIONS]. For example, to develop a protocol that runs
directly above IP, one needs an IP Protocol Number to place in the directly above IP, one needs an IP Protocol Number to place in the
Protocol field of the IP header [RFC791]. In some cases, obtaining a Protocol field of the IP header [RFC791]. In some cases, obtaining a
new number is straightforward (e.g., a well-known TCP or UDP port) or new number is straightforward (e.g., a well-known TCP or UDP port) or
not even necessary (e.g., TCP and UDP port numbers for testing not even necessary (e.g., TCP and UDP port numbers for testing
purposes). In other cases, obtaining a number is more difficult. For purposes). In other cases, obtaining a number is more difficult. For
example, the number of available and unassigned values in a name example, the number of available and unassigned values in a name
space may be small enough that there is concern that all available space may be small enough that there is concern that all available
numbers will be used up if assigned carelessly. Even in cases where numbers will be used up if assigned carelessly. Even in cases where
number are potentially plentiful, it may be desired that numbers not numbers are potentially plentiful, it may be undesirable to assign
be assigned unless the proposed usage has been adequately reviewed by numbers unless the proposed usage has been adequately reviewed by the
the broader community. Consequently, some number spaces specify that broader community. Consequently, some number spaces specify that IANA
IANA only make assignments in cases where there is strong community only make assignments in cases where there is strong community
support for a proposed protocol. For example, values out of some name support for a proposed protocol. For example, values out of some name
spaces are only assigned through an "IETF Standards Action" [IANA- spaces are only assigned through an "IETF Standards Action" [IANA-
CONSIDERATIONS], which requires that the proposed use be in an IETF CONSIDERATIONS], which requires that the proposed use be in an IETF
Standards Track RFC. Standards Track RFC.
In order to experiment with a new protocol, an experimental value may In order to experiment with a new protocol, an experimental value may
be needed that won't collide with an existing or future usage. be needed that won't collide with an existing or future usage.
One approach is to allow IANA to make temporary assignments for such One approach is to allow IANA to make temporary assignments for such
purposes. The idea is that a protocol value can be assigned to allow purposes. The idea is that a protocol value can be assigned to allow
skipping to change at page 4, line 14 skipping to change at page 4, line 16
extension, the device will either ignore the PDU, discard it, or extension, the device will either ignore the PDU, discard it, or
signal an error, depending on the protocol-specific rules that signal an error, depending on the protocol-specific rules that
indicate how to process unknown options or features. In those cases indicate how to process unknown options or features. In those cases
where a protocol has different ways of handling unrecognized where a protocol has different ways of handling unrecognized
extensions (e.g., silently discard vs. signal an error), that extensions (e.g., silently discard vs. signal an error), that
protocol needs to reserve values for testing purposes from all the protocol needs to reserve values for testing purposes from all the
appropriate ranges. Only those implementations specifically enabled appropriate ranges. Only those implementations specifically enabled
or configured to make use of an extension or feature that is being or configured to make use of an extension or feature that is being
experimented with would process the data further. experimented with would process the data further.
1.1. Recommendation for Protocols
To make it possible to experiment with protocol extensions safely,
protocol documents should consider reserving a small set of protocol
numbers for experimentation. Such reservations can be made through an
explicite reservation in an IANA Considerations section.
The exact number of values to reserve for experimentation will depend The exact number of values to reserve for experimentation will depend
on the specific protocol and factors specific to that protocol. For on the specific protocol and factors specific to that protocol. For
example, in cases where the values of a field are subdivided into example, in cases where the values of a field are subdivided into
ranges that are treated differently (e.g., "silently ignore" vs. ranges that are treated differently (e.g., "silently ignore" vs.
"return an error" if the value is not understood), one or more values "return an error" if the value is not understood), one or more values
from each sub-range may need to be reserved. from each sub-range may need to be reserved.
For protocols that return error codes, it may also be appropriate to
reserve a small number of experimental error values that can be used
in conjunction with possible experimental uses. For example, an
experimental message might result (even under normal conditions) in
an error, with a special error code (or sub-code) indicating the type
of error condition.
In many, if not most cases, reserving a single value for experimental In many, if not most cases, reserving a single value for experimental
use will suffice. While it may be tempting to reserve more in order use will suffice. While it may be tempting to reserve more in order
to make it easy to test many things at once, reserving many may also to make it easy to test many things at once, reserving many may also
increase the temptation for someone using a particular value to increase the temptation for someone using a particular value to
assume that a specific experimental value can be used for a given assume that a specific experimental value can be used for a given
purpose exclusively. Values reserved for experimental use are never purpose exclusively. Values reserved for experimental use are never
to be made permanent; permanent assignments should be obtained to be made permanent; permanent assignments should be obtained
through standard processes. As described above, experimental numbers through standard processes. As described above, experimental numbers
are intended for experimentation and testing and are not intended for are intended for experimentation and testing and are not intended for
wide or general deployments. wide or general deployments.
skipping to change at page 5, line 10 skipping to change at page 5, line 25
2.1. IP Protocol Field 2.1. IP Protocol Field
Assignment of new values for the IP Protocol field requires an IETF Assignment of new values for the IP Protocol field requires an IETF
Standards Action per [RFC2780]. For the purposes of experimentation Standards Action per [RFC2780]. For the purposes of experimentation
and testing, IANA has assigned the two values TBD1 and TBD2 for this and testing, IANA has assigned the two values TBD1 and TBD2 for this
purpose. These values have been allocated from the upper end of the purpose. These values have been allocated from the upper end of the
available number space in order to make them easy to identify by available number space in order to make them easy to identify by
having them stand out relative to the existing assignments that have having them stand out relative to the existing assignments that have
been made. been made.
Existing Name Spaces 2.2. Existing Name Spaces
Numerous name spaces exist for which no values have been reserved for Numerous name spaces exist for which no values have been reserved for
experimentation or testing purpose. Experimental values for such experimentation or testing purpose. Experimental values for such
protocols can of course be assigned through the normal process of protocols can of course be assigned through the normal process of
publishing an RFC that documents the details of such an allocation. publishing an RFC that documents the details of such an allocation.
To simplify the process in those cases where the publication of a To simplify the process in those cases where the publication of a
documentation just for the purpose of assigning an experimental documentation just for the purpose of assigning an experimental
allocation seems overkill, experimental values can be made through allocation seems overkill, experimental values can be made through
IESG Approval [RFC2434]. IESG Approval [RFC2434].
 End of changes. 11 change blocks. 
12 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/