IANA Allocation Guidelines for the Protocol Field
Ericsson
Jorvas 02420
Finland
jari.arkko@piuha.net
Harvard University
Cambridge
MA
02138
US
+1 617 495 3864
sob@harvard.edu
IANA rules
IPv4
IPv6
Protocol field
Next header field
This document revises the IANA guidelines for allocating new
Protocol field values in IPv4, as well as new Next Header field values
in IPv6. It modifies the rules specified in RFC 2780 by removing the
Expert Review option.
This document revises the IANA guidelines for allocating new
Protocol field values in IPv4. The same guidelines will also apply for
IPv6 Next Header values.
Previously, RFC 2780 allowed such allocations to happen through
IESG Approval, Standards action, or Expert Review processes . The Expert Review process
was specified to be used only in the case where a non-disclosure
agreement was involved:
IANA allocates values from the IPv4 Protocol name space following an
Expert Review, IESG Approval or Standards Action process. The Expert
Review process should only be used in those special cases where non-
disclosure information is involved. In these cases the expert(s)
should be designated by the IESG.
The need for the Standards Action rule is obvious as the IETF keeps
developing new protocols. It is equally obvious that there is a need
to allow experimental allocations in this space, see RFC 4727 for an example. Similarly, there are
cases when it makes sense to allocate values out of this space for
other non- Standards Track or non-IETF uses. However, the size of the
field is 256 values, and 55% of these were in use at the time this
document was written. As a result, a sanity check is needed to ensure
that allocations are not made needlessly. RFC 2780 specifies the IESG
Approval rule to take care of these sanity checks for the
non-Standards Track cases. The judgment call can take into account
the existence of a stable protocol specification, constituency that
wants to use it, need to avoid duplicated allocations for the same
purpose, whether protocol number allocation is the right solution for
this problem as opposed to, say, a TCP port, and so on.
However, we now believe that the non-disclosure agreement option is
not appropriate for allocations in this space. Traditionally,
non-disclosure agreements have been used by the IANA when a company
was developing a proprietary protocol and did not want to disclose new
areas of research or future products. The protocol space is limited
enough that we no longer believe that it is reasonable to use of the
resource for such proprietary protocols. Thus, we believe that
allocations should only be made using the IESG Approval or Standards
Action processes when there are public specifications that can be
reviewed.
As a result, this document revises the RFC 2780 rules by removing
the option for Expert Review for the IPv4 Protocol and IPv6 Next
Header fields. This document takes no position on the allocation of
other parameters with non-disclosure agreements, as those parameters
may require different policies.
This document replaces the current rule in section 4.3 with the
following:
IANA allocates values from the IPv4 Protocol name space following
an IESG Approval or Standards Action process.
This document makes no change to the rule for the IPv6 Next Header
field in Section 5.3 but notes that the rule in section 4.3 that is
referred to is the revised one without the Expert Review option.
This specification does not change the security properties
of the affected protocols.
Issues with the original RFC 2780 rules were uncovered in
discussions of the IETF - IANA team. The team also provided background
information on the practical difficulties encountered with
non-disclosure agreements. The authors would like to thank Thomas
Narten, Bill Fenner, and Michelle Cotton in particular.