RFC3692 日本語訳

Network Working Group                                          T. Narten
Request for Comments: 3692                                           IBM
BCP: 82                                                     January 2004
Updates: 2434
Category: Best Current Practice

Network Working Group T. Narten Request for Comments: 3692 IBM BCP: 82 January 2004 Updates: 2434 Category: Best Current Practice

      Assigning Experimental and Testing Numbers Considered Useful

Assigning Experimental and Testing Numbers Considered Useful

Status of this Memo

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

Copyright Notice

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

Abstract

   When experimenting with or extending protocols, it is often necessary
   to use some sort of protocol number or constant in order to actually
   test or experiment with the new function, even when testing in a
   closed environment.  For example, to test a new DHCP option, one
   needs an option number to identify the new function.  This document
   recommends that when writing IANA Considerations sections, authors
   should consider assigning a small range of numbers for
   experimentation purposes that implementers can use when testing
   protocol extensions or other new features.  This document reserves
   some ranges of numbers for experimentation purposes in specific
   protocols where the need to support experimentation has been
   identified.

When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.

Table of Contents

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Recommendation for Protocols . . . . . . . . . . . . . .  4
   2.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  5
       2.1.  IP Protocol Field. . . . . . . . . . . . . . . . . . . .  5
       2.2.  Existing Name Spaces . . . . . . . . . . . . . . . . . .  5
   3.  Security Considerations. . . . . . . . . . . . . . . . . . . .  5
   4.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
       5.1.  Normative References . . . . . . . . . . . . . . . . . .  5
       5.2.  Informative References . . . . . . . . . . . . . . . . .  6
   6.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
   7.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  7

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Recommendation for Protocols . . . . . . . . . . . . . . 4 2. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 5 2.1. IP Protocol Field. . . . . . . . . . . . . . . . . . . . 5 2.2. Existing Name Spaces . . . . . . . . . . . . . . . . . . 5 3. Security Considerations. . . . . . . . . . . . . . . . . . . . 5 4. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 5.2. Informative References . . . . . . . . . . . . . . . . . 6 6. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 7. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7

Narten                   Best Current Practice                  [Page 1]

RFC 3692       Assigning Experimental and Testing Numbers   January 2004

Narten Best Current Practice [Page 1]  RFC 3692 Assigning Experimental and Testing Numbers January 2004

1.  Introduction

1. Introduction

   When experimenting with or extending protocols, it is often necessary
   to have a protocol number as part of the implementation [RFC2434].
   For example, to develop a protocol that runs 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 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 purposes).  In
   other cases, obtaining a number is more difficult.  For example, the
   number of available and unassigned values in a name 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 are
   potentially plentiful, it may be undesirable to assign numbers unless
   the proposed usage has been adequately reviewed by the broader
   community.  Consequently, some number spaces specify that IANA only
   make assignments in cases where there is strong community support for
   a proposed protocol.  For example, values out of some name spaces are
   only assigned through an "IETF Standards Action" [RFC2434], which
   requires that the proposed use be in an IETF Standards Track RFC.

When experimenting with or extending protocols, it is often necessary to have a protocol number as part of the implementation [RFC2434]. For example, to develop a protocol that runs 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 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 purposes). In other cases, obtaining a number is more difficult. For example, the number of available and unassigned values in a name 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 are potentially plentiful, it may be undesirable to assign numbers unless the proposed usage has been adequately reviewed by the broader community. Consequently, some number spaces specify that IANA only make assignments in cases where there is strong community support for a proposed protocol. For example, values out of some name spaces are only assigned through an "IETF Standards Action" [RFC2434], which requires that the proposed use be in an IETF Standards Track RFC.

   In order to experiment with a new protocol, an experimental value may
   be needed that won't collide with an existing or future usage.

In order to experiment with a new protocol, an experimental value may be needed that won't collide with an existing or future usage.

   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
   experimentation, but after the experiment ends, the number would be
   returned to IANA.  There are several drawbacks to this approach,
   however.  First, experience has shown that it can be difficult to
   reclaim numbers once assigned.  For example, contact information
   becomes outdated and it can become difficult to find out what the
   status of an experiment actually is.  Second, should deployment with
   the temporarily assigned number take place (e.g., it is included as
   part of a product), it becomes very difficult to determine whether or
   not reuse of that number would lead to adverse impact with regards to
   deployed devices.  Finally, it can be difficult to determine when an
   experiment has ended and whether the number needs to be returned.

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 experimentation, but after the experiment ends, the number would be returned to IANA. There are several drawbacks to this approach, however. First, experience has shown that it can be difficult to reclaim numbers once assigned. For example, contact information becomes outdated and it can become difficult to find out what the status of an experiment actually is. Second, should deployment with the temporarily assigned number take place (e.g., it is included as part of a product), it becomes very difficult to determine whether or not reuse of that number would lead to adverse impact with regards to deployed devices. Finally, it can be difficult to determine when an experiment has ended and whether the number needs to be returned.

   An alternate approach, and the one recommended in this document, is
   to assign a range of numbers specifically earmarked for testing and
   experimentation purposes.  Mutually consenting devices could use
   these numbers for whatever purposes they desire, but under the
   understanding that they are reserved for generic testing purposes,
   and other implementations may use the same numbers for different
   experimental uses.

An alternate approach, and the one recommended in this document, is to assign a range of numbers specifically earmarked for testing and experimentation purposes. Mutually consenting devices could use these numbers for whatever purposes they desire, but under the understanding that they are reserved for generic testing purposes, and other implementations may use the same numbers for different experimental uses.

Narten                   Best Current Practice                  [Page 2]

RFC 3692       Assigning Experimental and Testing Numbers   January 2004

Narten Best Current Practice [Page 2]  RFC 3692 Assigning Experimental and Testing Numbers January 2004

   Numbers in the experimentation range are similar to those called
   "Private Use" in RFC 2434 [IANA-CONSIDERATIONS].  They are not
   intended to be used in general deployments or be enabled by default
   in products or other general releases.  In those cases where a
   product or release makes use of an experimental number, the end user
   must be required to explicitly enable the experimental feature and
   likewise have the ability to chose and assign which number from the
   experimental range will be used for a specific purpose (i.e., so the
   end user can ensure that use of a particular number doesn't conflict
   with other on-going uses).  Shipping a product with a specific value
   pre-enabled would be inappropriate and can lead to interoperability
   problems when the chosen value collides with a different usage, as it
   someday surely will.

Numbers in the experimentation range are similar to those called "Private Use" in RFC 2434 [IANA-CONSIDERATIONS]. They are not intended to be used in general deployments or be enabled by default in products or other general releases. In those cases where a product or release makes use of an experimental number, the end user must be required to explicitly enable the experimental feature and likewise have the ability to chose and assign which number from the experimental range will be used for a specific purpose (i.e., so the end user can ensure that use of a particular number doesn't conflict with other on-going uses). Shipping a product with a specific value pre-enabled would be inappropriate and can lead to interoperability problems when the chosen value collides with a different usage, as it someday surely will.

   From the above, it follows that it would be inappropriate for a group
   of vendors, a consortia, or another Standards Development
   Organization to agree among themselves to use a particular value for
   a specific purpose and then agree to deploy devices using those
   values.  By definition, experimental numbers are not guaranteed to be
   unique in any environment other than one where the local system
   administrator has chosen to use a particular number for a particular
   purpose and can ensure that a particular value is not already in use
   for some other purpose.

From the above, it follows that it would be inappropriate for a group of vendors, a consortia, or another Standards Development Organization to agree among themselves to use a particular value for a specific purpose and then agree to deploy devices using those values. By definition, experimental numbers are not guaranteed to be unique in any environment other than one where the local system administrator has chosen to use a particular number for a particular purpose and can ensure that a particular value is not already in use for some other purpose.

   Once an extension has been tested and shown to be useful, a permanent
   number could be obtained through the normal assignment procedures.

Once an extension has been tested and shown to be useful, a permanent number could be obtained through the normal assignment procedures.

   Most implementations will not do anything special with numbers
   assigned for testing purposes.  In particular, unless a packet or
   other Protocol Data Unit (PDU) is specifically directed at a device,
   that device will not even look at the field while processing the PDU.
   For example, IP routers do not need to examine or understand the
   Protocol Type field of IP datagrams in order to know how to correctly
   forward them.  In those cases where a packet or PDU is directed at a
   device, and that device has not been configured to recognize the
   extension, the device will either ignore the PDU, discard it, or
   signal an error, depending on the protocol-specific rules that
   indicate how to process unknown options or features.  In those cases
   where a protocol has different ways of handling unrecognized
   extensions (e.g., silently discard vs. signal an error), that
   protocol needs to reserve values for testing purposes from all the
   appropriate ranges.  Only those implementations specifically enabled
   or configured to make use of an extension or feature that is being
   experimented with would process the data further.

Most implementations will not do anything special with numbers assigned for testing purposes. In particular, unless a packet or other Protocol Data Unit (PDU) is specifically directed at a device, that device will not even look at the field while processing the PDU. For example, IP routers do not need to examine or understand the Protocol Type field of IP datagrams in order to know how to correctly forward them. In those cases where a packet or PDU is directed at a device, and that device has not been configured to recognize the extension, the device will either ignore the PDU, discard it, or signal an error, depending on the protocol-specific rules that indicate how to process unknown options or features. In those cases where a protocol has different ways of handling unrecognized extensions (e.g., silently discard vs. signal an error), that protocol needs to reserve values for testing purposes from all the appropriate ranges. Only those implementations specifically enabled or configured to make use of an extension or feature that is being experimented with would process the data further.

Narten                   Best Current Practice                  [Page 3]

RFC 3692       Assigning Experimental and Testing Numbers   January 2004

Narten Best Current Practice [Page 3]  RFC 3692 Assigning Experimental and Testing Numbers January 2004

1.1.  Recommendation for Protocols

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 explicit reservation in an IANA Considerations section.

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 explicit reservation in an IANA Considerations section.

   The exact number of values to reserve for experimentation will depend
   on the specific protocol and factors specific to that protocol.  For
   example, in cases where the values of a field are subdivided into
   ranges that are treated differently (e.g., "silently ignore" vs.
   "return an error" if the value is not understood), one or more values
   from each sub-range may need to be reserved.

The exact number of values to reserve for experimentation will depend on the specific protocol and factors specific to that protocol. For example, in cases where the values of a field are subdivided into ranges that are treated differently (e.g., "silently ignore" vs. "return an error" if the value is not understood), one or more values 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.

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
   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
   increase the temptation for someone using a particular value to
   assume that a specific experimental value can be used for a given
   purpose exclusively.  Values reserved for experimental use are never
   to be made permanent; permanent assignments should be obtained
   through standard processes.  As described above, experimental numbers
   are intended for experimentation and testing and are not intended for
   wide or general deployments.

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 to make it easy to test many things at once, reserving many may also increase the temptation for someone using a particular value to assume that a specific experimental value can be used for a given purpose exclusively. Values reserved for experimental use are never to be made permanent; permanent assignments should be obtained through standard processes. As described above, experimental numbers are intended for experimentation and testing and are not intended for wide or general deployments.

   When protocols that use experimental numbers are included in
   products, the shipping versions of the products must disable
   recognition of protocol experimental numbers by default -- that is,
   the end user of the product must explicitly "turn on" the
   experimental protocol functionality.  In most cases, a product
   implementation must require the end user to configure the value
   explicitly prior to enabling its usage.  Should a product not have a
   user interface for such end user configuration, the product must
   require explicit re-programming (e.g., a special firmware download,
   or installation of a feature card) to configure the experimental
   number(s) of the protocol(s) implicitly.

When protocols that use experimental numbers are included in products, the shipping versions of the products must disable recognition of protocol experimental numbers by default -- that is, the end user of the product must explicitly "turn on" the experimental protocol functionality. In most cases, a product implementation must require the end user to configure the value explicitly prior to enabling its usage. Should a product not have a user interface for such end user configuration, the product must require explicit re-programming (e.g., a special firmware download, or installation of a feature card) to configure the experimental number(s) of the protocol(s) implicitly.

Narten                   Best Current Practice                  [Page 4]

RFC 3692       Assigning Experimental and Testing Numbers   January 2004

Narten Best Current Practice [Page 4]  RFC 3692 Assigning Experimental and Testing Numbers January 2004

2.  IANA Considerations

2. IANA Considerations

2.1.  IP Protocol Field

2.1. IP Protocol Field

   Assignment of new values for the IP Protocol field requires an IETF
   Standards Action per [RFC2780].  For the purposes of experimentation
   and testing, IANA has assigned the two values 253 and 254 for this
   purpose.  These values have been allocated from the upper end of the
   available number space in order to make them easy to identify by
   having them stand out relative to the existing assignments that have
   been made.

Assignment of new values for the IP Protocol field requires an IETF Standards Action per [RFC2780]. For the purposes of experimentation and testing, IANA has assigned the two values 253 and 254 for this purpose. These values have been allocated from the upper end of the available number space in order to make them easy to identify by having them stand out relative to the existing assignments that have been made.

2.2.  Existing Name Spaces

2.2. Existing Name Spaces

   Numerous name spaces exist for which no values have been reserved for
   experimentation or testing purpose.  Experimental values for such
   protocols can of course be assigned through the normal process of
   publishing an RFC that documents the details of such an allocation.
   To simplify the process in those cases where the publication of a
   documentation just for the purpose of assigning an experimental
   allocation seems overkill, experimental values can be made through
   IESG Approval [RFC2434].

Numerous name spaces exist for which no values have been reserved for experimentation or testing purpose. Experimental values for such protocols can of course be assigned through the normal process of publishing an RFC that documents the details of such an allocation. To simplify the process in those cases where the publication of a documentation just for the purpose of assigning an experimental allocation seems overkill, experimental values can be made through IESG Approval [RFC2434].

3.  Security Considerations

3. Security Considerations

   This document has no known security implications.

This document has no known security implications.

4.  Acknowledgments

4. Acknowledgments

   Improvements to this document came as a result of specific feedback
   from Steve Bellovin, Scott Bradner, Randy Bush, Bill Fenner, Steve
   Hanna, Paul Hoffman, Henrik Levkowetz, John Loughney, Allison Mankin,
   and Richard Woundy.

Improvements to this document came as a result of specific feedback from Steve Bellovin, Scott Bradner, Randy Bush, Bill Fenner, Steve Hanna, Paul Hoffman, Henrik Levkowetz, John Loughney, Allison Mankin, and Richard Woundy.

5.  References

5. References

5.1.  Normative References

5.1. Normative References

   [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
             Values In the Internet Protocol and Related Headers", BCP
             37, RFC 2780, March 2000.

[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October 1998.

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

Narten                   Best Current Practice                  [Page 5]

RFC 3692       Assigning Experimental and Testing Numbers   January 2004

Narten Best Current Practice [Page 5]  RFC 3692 Assigning Experimental and Testing Numbers January 2004

5.2.  Informative References

5.2. Informative References

   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
             1981.

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

6.  Author's Address

6. Author's Address

   Thomas Narten
   IBM Corporation
   P.O. Box 12195
   Research Triangle Park, NC 27709-2195
   USA

Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA

   Phone: +1 919 254 7798
   EMail: narten@us.ibm.com

Phone: +1 919 254 7798 EMail: narten@us.ibm.com

Narten                   Best Current Practice                  [Page 6]

RFC 3692       Assigning Experimental and Testing Numbers   January 2004

Narten Best Current Practice [Page 6]  RFC 3692 Assigning Experimental and Testing Numbers January 2004

7.  Full Copyright Statement

7. Full Copyright Statement

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Funding for the RFC Editor function is currently provided by the Internet Society.

Narten                   Best Current Practice                  [Page 7]

Narten Best Current Practice [Page 7]