Network Working Group J. Arkko
Internet-Draft Ericsson
Updates: 5191 (if approved) A. Yegin
Intended status: Standards Track Samsung
Expires: August 15, 2010 February 11, 2010
IANA Rules for Protocol for Carrying Authentication for Network Access
(PANA)
draft-arkko-pana-iana-01
Abstract
This document relaxes the IANA rules for Protocol for Carrying
Authentication for Network Access (PANA).
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2010.
Copyright Notice
Copyright (c) 2010 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
Arkko & Yegin Expires August 15, 2010 [Page 1]
Internet-Draft PANA IANA Rules February 2010
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 BSD License.
1. Introduction
This document relaxes the IANA rules for Protocol for Carrying
Authentication for Network Access (PANA) [RFC5191]. Rules for the
following protocol fields, all defined in [RFC5191], are affected:
o Message Type
o Message Flags
o AVP Flags
o Result-Code Attribute-Value Pair (AVP) Value
o 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 [RFC5226], 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.
2. IANA Considerations
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.
2.1. Message Type
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,
Arkko & Yegin Expires August 15, 2010 [Page 2]
Internet-Draft PANA IANA Rules February 2010
allocated by IETF Review or IESG approval [RFC5226]. Previously, the
rule for this range was allocation by IETF Review only. [RFC5191]
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 [RFC3692].
2.2. Message Flags
There are 16 bits in the Flags field of the PANA message header.
Section 6.2 of [RFC5191] 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 [RFC5226]. Previously, the rule for these bits was
allocation by Standards Action only.
2.3. AVP Flags
There are 16 bits in the AVP Flags field of the AVP header, defined
in Section 6.3 of [RFC5191]. That RFC also assigned bit 0 ('V').
The remaining bits are assigned via a Standards Action or IESG
Approval [RFC5226]. Previously, the rule for these bits was
allocation by Standards Action only.
2.4. Result-Code AVP Values
As defined in Section 8.7 of [RFC5191], 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 [RFC5226]. Previously, the rule for these bits was
allocation by IETF Review only.
2.5. Termination-Cause AVP Values
As defined in Section 8.9 of [RFC5191], 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 [RFC5226]. Previously, the rule for these bits was
allocation by IETF Review only.
Arkko & Yegin Expires August 15, 2010 [Page 3]
Internet-Draft PANA IANA Rules February 2010
3. Security Considerations
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 Section 2.1. 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
[RFC3692] about the use of experimental values needs to be followed.
4. References
4.1. Normative References
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
4.2. Informative References
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
Appendix A. Changes from RFC 5191
This document changes the IANA rules for the Message Type, Message
Flags, AVP Flags, Result-Code Attribute-Value Pair (AVP) Value, and
Termination-Cause AVP Value.
Appendix B. Acknowledgments
The authors would like to thank Yoshihiro Ohba and Ralph Droms for
reviews and comments.
Arkko & Yegin Expires August 15, 2010 [Page 4]
Internet-Draft PANA IANA Rules February 2010
Authors' Addresses
Jari Arkko
Ericsson
Jorvas 02420
Finland
Email: jari.arkko@piuha.net
Alper Yegin
Samsung
Istanbul
Turkey
Email: alper.yegin@yegin.org
Arkko & Yegin Expires August 15, 2010 [Page 5]