IANA Rules for PANA (Protocol for Carrying Authentication for Network Access)
Ericsson
Jorvas 02420
Finland
jari.arkko@piuha.net
Samsung
Istanbul
Turkey
alper.yegin@yegin.org
IANA rules
PANA
This document relaxes the IANA rules for the Protocol for Carrying
Authentication for Network Access (PANA).
This document relaxes the IANA rules for the Protocol for Carrying
Authentication for Network Access (PANA)
. Rules for the following protocol fields, all
defined in , are affected:
Message Type
Message Flags
Attribute-Value Pair (AVP) Flags
Result-Code AVP Value
Termination-Cause AVP Value
The rationale for this update is that there can be situations where
it makes sense to grant an allocation under special circumstances. At
the time of writing this, one such allocation is currently in the
approval process at the IETF. By changing the current IANA rules to
allow also for IESG Approval , it becomes
possible for the Internet Engineering Steering Group (IESG) to
consider an allocation request, even if it does not fulfill the
default rule. For instance, an experimental protocol extension could
perhaps deserve an allocation from a field of reserved bits, as long
as a sufficient number of bits still remains for other purposes, and
the PANA community is happy with such an allocation.
IANA is requested to updated the registries related to PANA Message
Types, Message Flags, AVP Flags, Result-Code AVP Values, and
Termination-Cause AVP Values as specified below. All other PANA IANA
registries are to remain unchanged.
The Message Type namespace is used to identify PANA messages.
Message Type 0 is not used and is not assigned by IANA. The range of
values 1 - 65,519 are for permanent, standard message types, allocated
by IETF Review or IESG approval . Previously,
the rule for this range was allocation by IETF Review only.
defined the range of values 1 - 4. The same
Message Type is used for both the request and the answer messages,
except for type 1. The Request bit distinguishes requests from
answers.
The range of values 65,520 - 65,535 (hexadecimal values 0xfff0 -
0xffff) are reserved for experimental messages. As these codes are
only for experimental and testing purposes, no guarantee is made for
interoperability between the communicating PANA Client (PaC) and PANA
Authentication Agent (PAA) using experimental commands, as outlined in
.
There are 16 bits in the Flags field of the PANA message header.
Section 6.2 of assigned bit 0 ('R'), 1 ('S'),
2 ('C'), 3 ('A'), 4 ('P'), and 5 ('I'). Allocations from the remaining
free bits in the PANA header Flag field are done via Standards Action
or IESG Approval .
Previously,
the rule for these bits was allocation by Standards Action only.
There are 16 bits in the AVP Flags field of the AVP header, defined
in Section 6.3 of . That RFC also assigned bit
0 ('V'). The remaining bits are assigned via a Standards Action or
IESG Approval .
Previously,
the rule for these bits was allocation by Standards Action only.
As defined in Section 8.7 of , the
Result-Code AVP (AVP Code 7) defines the values 0-2.
All remaining values are available for assignment via IETF
Review or IESG Approval .
Previously,
the rule for these bits was allocation by IETF Review only.
As defined in Section 8.9 of , the
Termination-Cause AVP (AVP Code 9) defines the values 1, 4, and
8.
All remaining values are available for assignment via IETF Review
or IESG Approval . Previously, the rule for
these bits was allocation by IETF Review only.
This specification does not change the security properties of
PANA.
However, a few words are necessary about the use of the
experimental code points defined in . Potentially
harmful side-effects from the use of the experimental values needs to
be carefully evaluated before deploying any experiment across networks
that the owner of the experiment does not entirely control. Guidance
given in about the use of experimental values
needs to be followed.
This document changes the IANA rules for the Message Type, Message
Flags, AVP Flags, Result-Code AVP Value, and Termination-Cause AVP
Value.
The authors would like to thank Yoshihiro Ohba, Ralph Droms, Magnus Westerlund, and Alfred Hoenes for
reviews and comments on this topic.