Subject: [Pana] a new issue: IANA considerations

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 15 Jul 2004 21:02:30 -0400

Here is initial text for IANA Considerations section of the PANA
specification.

Comments are appreciated.

-----------------------------------
[1] Update Section 8 as follows:

"
8. IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the
   PANA protocol, in accordance with BCP 26 [IANA].  The following
   policies are used here with the meanings defined in BCP 26:
   "Private Use", "First Come First Served", "Expert Review",
   "Specification Required", "IETF Consensus", "Standards Action".

   This section explains the criteria to be used by the IANA for
   assignment of numbers within namespaces defined within this document.

   For registration requests where a Designated Expert should be
   consulted, the responsible IESG area director should appoint the
   Designated Expert.  For Designated Expert with Specification
   Required, the request is posted to the PANA WG mailing list (or, if
   it has been disbanded, a successor designated by the Area Director)
   for comment and review, and MUST include a pointer to a public
   specification.  Before a period of 30 days has passed, the Designated
   Expert will either approve or deny the registration request and
   publish a notice of the decision to the PANA WG mailing list or its
   successor.  A denial notice must be justified by an explanation and,
   in the cases where it is possible, concrete suggestions on how the
   request can be modified so as to become acceptable.

8.1 PANA UDP Port Number

   PANA uses one well-known UDP port number (Section 4.1.2, Section
   4.2 and Section 6.1), which needs to be assigned by the IANA.

8.2 PANA Multicast Address

   PANA uses one well-known IPv4 multicast address for which the scope
   is limited to be link-local by setting the TTL field to 255, and
   one well-known IPv6 link-local scoped multicast address (Section
   4.2 and Section 6.1), which need to be assigned by the IANA.

8.3 PANA Header

   As defined in Section 6.2, the PANA header contains two fields that
   requires IANA namespace management; the Message Type and Flags
   field.

8.3.1 Message Type

   The Message Type namespace is used to identify PANA messages.
   Values 0-16,777,213 are for permanent, standard message types,
   allocated by IETF Consensus [IANA].  This document defines the
   Message Types 1-8.  See Section 6.4 for the assignment of the
   namespace in this specification.

   The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe -
   0xffffff) are reserved for experimental messages.  As these codes
   are only for experimental and testing purposes, no guarantee is
   made for interoperability between communicating PaC and PAA using
   experimental commands, as outlined in [IANA-EXP].

8.3.2 Flags

   There are eight bits in the Flags field of the PANA header.  This
   document assigns bit 0 ('R'equest), bit 4 ('S'eparate) and bit 5
   ('N'AP Authentication).  The remaining bits MUST only be assigned
   via a Standards Action [IANA].

8.4 AVP Header

   As defined in Section 6.3, the AVP header contains three fields
   that requires IANA namespace management; the AVP Code, AVP Flags
   and Vendor-Id fields where only the AVP Code and AVP Flags create
   new namespaces.

8.4.1 AVP Code

   The AVP Code namespace is used to identify attributes.  There are
   multiple namespaces.  Vendors can have their own AVP Codes
   namespace which will be identified by their Vendor-ID (also known
   as Enterprise-Number) and they control the assignments of their
   vendor-specific AVP codes within their own namespace.  The absence
   of a Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF
   IANA controlled AVP Codes namespace.  The AVP Codes and sometimes
   also possible values in an AVP are controlled and maintained by
   IANA.

   AVP Code 0 is not used.  This document defines the AVP Codes
   1024-1041.  See Section 6.5 for the assignment of the namespace in
   this specification.

   AVPs may be allocated following Designated Expert with Specification
   Required [IANA].  Release of blocks of AVPs (more than 3 at a time
   for a given purpose) should require IETF Consensus.

   Note that PANA defines a mechanism for Vendor-Specific AVPs, where
   the Vendor-Id field in the AVP header is set to a non-zero value.
   Vendor-Specific AVPs codes are for Private Use and should be
   encouraged instead of allocation of global attribute types, for
   functions specific only to one vendor's implementation of PANA,
   where no interoperability is deemed useful.  Where a
   Vendor-Specific AVP is implemented by more than one vendor,
   allocation of global AVPs should be encouraged instead.

8.4.2 AVP Flags

   There are 8 bits in the AVP Flags field of the AVP header, defined
   in Section 6.3.  This document assigns bit 0 ('V'endor Specific)
   and bit 1 ('M'andatory).  The remaining bits should only be
   assigned via a Standards Action [IANA].

8.5 AVP Values

   Certain AVPs in PANA define a list of values with various meanings.
   For attributes other than those specified in this section, adding
   additional values to the list can be done on a First Come, First
   Served basis by IANA.

8.5.1 Algorithm Values of MAC AVP

   As defined in Section 6.5.1, the Algorithm field of MAC AVP (AVP
   Code 1024) defines the value of 1 (one) for HMAC-SHA1.

   All remaining values are available for assignment via IETF
   Consensus [IANA].

8.5.2 Protection-Capability AVP Values

   As defined in Section 6.5.5, the Protection-Capability AVP (AVP
   Code 1028) defines the values 0 and 1.

   All remaining values are available for assignment via a Standards
   Action [IANA].

8.5.3 Termination-Cause AVP Values

   As defined in Section 6.5.6, the Termination-Cause AVP (AVP Code
   1029) defines the values 1, 4 and 8.

   All remaining values are available for assignment via IETF
   Consensus [IANA].

8.5.4 Result-Code AVP Values

   As defined in Section 6.5.7, the Result-Code AVP (AVP Code 1030)
   defines the values 2001, 3001-3002, 3008-3009, 4001, 5001-5009 and
   5011-5019.

   All remaining values are available for assignment via IETF Consensus
   [IANA].

8.5.5 Post-PANA-Address-Configuration AVP Values

   As defined in Section 6.5.17, the Post-PANA-Address-Configuration
   AVP (AVP Code 1040) defines the bits 0 ('N': no configuration), 1
   ('D': DHCP), 2 ('A' stateless autoconfiguration), 3 ('T': DHCP with
   IPsec tunnel mode) and 4 ('I': IKEv2).

   All remaining values are available for assignment via a Standards
   Action [IANA].

"

[2] Add the following informative reference:

"
[IANA-EXP] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
"

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana