PANA Working Group                                           D. Forsberg
Internet-Draft                                                     Nokia
Expires: February 23, 2007
Intended status: Standards Track                           Y. Ohba (Ed.)
Expires: June 9, 2007                                            Toshiba
                                                                B. Patil
                                                                   Nokia
                                                           H. Tschofenig
                                                                 Siemens
                                                                A. Yegin
                                                                 Samsung
                                                         August 22,
                                                        December 6, 2006

     Protocol for Carrying Authentication for Network Access (PANA)
                        draft-ietf-pana-pana-12
                        draft-ietf-pana-pana-13

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 February 23, June 9, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document defines the Protocol for Carrying Authentication for
   Network Access (PANA), a link-layer agnostic network-layer transport for Extensible
   Authentication Protocol (EAP) to enable network access authentication
   between clients and access networks.  PANA protocol specification
   covers the client-to-network access authentication part of an overall
   secure network access framework, which additionally includes other
   protocols and mechanisms for service provisioning, access control as
   a result of initial authentication, and accounting.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Specification of Requirements  . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7  6
   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  9  8
   4.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 11 10
     4.1.  Transport Layer  . . . . . . . . . . . . . . . . . . . . . 11 10
     4.2.  High-Level Attribute-Value Pair Description  . . . . . . . 11 10
     4.3.  Handshake Phase  . . . . . . . . . . . . . . . . . . . . . 12 10
     4.4.  Authentication and Authorization Phase . . . . . . . . . . 14 12
     4.5.  Access Phase . . . . . . . . . . . . . . . . . . . . . . . 17 14
     4.6.  Re-authentication Phase  . . . . . . . . . . . . . . . . . 18 14
     4.7.  Termination Phase  . . . . . . . . . . . . . . . . . . . . 19 16
   5.  Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 21 17
     5.1.  Fragmentation  . . . . . . . . . . . . . . . . . . . . . . 21 17
     5.2.  Sequence Number and Retransmission . . . . . . . . . . . . 21 17
     5.3.  PANA Security Association  . . . . . . . . . . . . . . . . 22 18
     5.4.  Message Authentication . . . . . . . . . . . . . . . . . . 24 19
     5.5.  Message Validity Check . . . . . . . . . . . . . . . . . . 24 20
     5.6.  PaC-EP-Master-Key  . . . . . . . . . . . . . . . . . . . . 25
     5.7.  Device ID Choice . . . . . . . . . . . . . . . . . . . . . 26
     5.8.  PaC Updating its IP Address  . . . . . . . . . . . . . . . 27
     5.9. 21
     5.7.  Session Lifetime . . . . . . . . . . . . . . . . . . . . . 27
     5.10. Network Selection  . . . . . . . . . . . . . . . . . . . . 28
     5.11. 21
     5.8.  Error Handling . . . . . . . . . . . . . . . . . . . . . . 29 22
   6.  Header Format  . . . . . . . . . . . . . . . . . . . . . . . . 30 24
     6.1.  IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 30 24
     6.2.  PANA Message Header  . . . . . . . . . . . . . . . . . . . . . . . 30 24
     6.3.  AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 32 26
   7.  PANA Messages  . . . . . . . . . . . . . . . . . . . . . . . . 35 29
     7.1.  PANA-Client-Initiation (PCI) . . . . . . . . . . . . . . . 37 31
     7.2.  PANA-Start-Request (PSR) . . . . . . . . . . . . . . . . . 37 31
     7.3.  PANA-Start-Answer (PSA)  . . . . . . . . . . . . . . . . . 38 31
     7.4.  PANA-Auth-Request (PAR)  . . . . . . . . . . . . . . . . . 38 32
     7.5.  PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 38 32
     7.6.  PANA-Reauth-Request (PRAR) (PRR)  . . . . . . . . . . . . . . . . 39 32
     7.7.  PANA-Reauth-Answer (PRAA) (PRA) . . . . . . . . . . . . . . . . 39 . 32
     7.8.  PANA-Bind-Request (PBR)  . . . . . . . . . . . . . . . . . 39 32
     7.9.  PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . . . 40 33
     7.10. PANA-Ping-Request (PPR)  . . . . . . . . . . . . . . . . . 40 33
     7.11. PANA-Ping-Answer (PPA) . . . . . . . . . . . . . . . . . . 40 33
     7.12. PANA-Termination-Request (PTR) . . . . . . . . . . . . . . 40 33
     7.13. PANA-Termination-Answer (PTA)  . . . . . . . . . . . . . . 41 34
     7.14. PANA-Error-Request (PER) . . . . . . . . . . . . . . . . . 41 34
     7.15. PANA-Error-Answer (PEA)  . . . . . . . . . . . . . . . . . 41 34
     7.16. PANA-Update-Request (PUR)  . . . . . . . . . . . . . . . . 41 34
     7.17. PANA-Update-Answer (PUA) . . . . . . . . . . . . . . . . . 42 34
   8.  AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . . . 43 36
     8.1.  Algorithm AVP  . . . . . . . . . . . . . . . . . . . . . . 45 37
     8.2.  AUTH AVP . . . . . . . . . . . . . . . . . . . . . . . . . 45 37
     8.3.  Cookie  EAP-Payload AVP  . . . . . . . . . . . . . . . . . . . . . . . . 46 37
     8.4.  Device-Id  Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . . 46 38
     8.5.  EAP-Payload  Failed-Message-Header AVP  . . . . . . . . . . . . . . . . 38
     8.6.  Key-Id AVP . . . . . 46
     8.6.  Failed-AVP AVP . . . . . . . . . . . . . . . . . . . 38
     8.7.  Nonce AVP  . . . 46
     8.7.  ISP-Information AVP . . . . . . . . . . . . . . . . . . . 46 . . 38
     8.8.  Key-Id  Result-Code AVP  . . . . . . . . . . . . . . . . . . . . . 39
       8.8.1.  Authentication Results Codes . . . 47
     8.9.  NAP-Information AVP  . . . . . . . . . . . 39
       8.8.2.  Protocol Error Result Codes  . . . . . . . . 47
     8.10. Nonce AVP . . . . . 39
     8.9.  Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 47
     8.11. Notification 42
     8.10. Termination-Cause AVP  . . . . . . . . . . . . . . . . . . 42
   9.  Retransmission Timers  . . . 48
     8.12. Post-PANA-Address-Configuration (PPAC) AVP . . . . . . . . 48
     8.13. Protection-Capability AVP . . . . . . . . . 43
     9.1.  Transmission and Retransmission Parameters . . . . . . . 50
     8.14. Provider-Identifier AVP . 44
   10. IANA Considerations  . . . . . . . . . . . . . . . . 50
     8.15. Provider-Name AVP . . . . . 46
     10.1. PANA UDP Port Number . . . . . . . . . . . . . . . 50
     8.16. Result-Code AVP . . . . 46
     10.2. PANA Message Header  . . . . . . . . . . . . . . . . . 50
       8.16.1.  Authentication Results Codes . . 46
       10.2.1. Version  . . . . . . . . . . 50
       8.16.2.  Protocol Error Result Codes . . . . . . . . . . . . . 51
     8.17. Session-Id AVP . . . . . . . . . . . . . . . . . . . . . . 53
     8.18. Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 54
     8.19. Termination-Cause AVP  . . . . . . . . . . . . . . . . . . 54
   9.  Retransmission Timers  . . . . . . . . . . . . . . . . . . . . 55
     9.1.  Transmission and Retransmission Parameters . . . . . . . . 56
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 58
     10.1. PANA UDP Port Number . . . . . . . . . . . . . . . . . . . 58
     10.2. PANA Header  . . . . . . . . . . . . . . . . . . . . . . . 58
       10.2.1. 46
       10.2.2. Message Type . . . . . . . . . . . . . . . . . . . . 58
       10.2.2. . 46
       10.2.3. Flags  . . . . . . . . . . . . . . . . . . . . . . . . 59 47
     10.3. AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 59 47
       10.3.1. AVP Code . . . . . . . . . . . . . . . . . . . . . . 59 . 47
       10.3.2. Flags  . . . . . . . . . . . . . . . . . . . . . . . . 59 48
     10.4. AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 60 48
       10.4.1.  Post-PANA-Address-Configuration AVP Values  . . . . . 60
       10.4.2.  Protection-Capability AVP Values  . . . . . . . . . . 60
       10.4.3. Result-Code AVP Values . . . . . . . . . . . . . . . 60
       10.4.4. . 48
       10.4.2. Termination-Cause AVP Values . . . . . . . . . . . . 60 . 48
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 61 49
     11.1. General Security Measures  . . . . . . . . . . . . . . . . 61 49
     11.2. Handshake  . . . . . . . . . . . . . . . . . . . . . . . . 62 50
     11.3. EAP Methods  . . . . . . . . . . . . . . . . . . . . . . . 63 51
     11.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . . 63 51
     11.5. Per-packet Ciphering . . . . . . . . . . . . . . . . . . . 64 51
     11.6. PAA-to-EP Communication  . . . . . . . . . . . . . . . . . 64 52
     11.7. Liveness Test  . . . . . . . . . . . . . . . . . . . . . . 64 52
     11.8. Updating PaC's IP Address Spoofing  . . . . . . . . . . . . . . . . 65 . . . 52
     11.9. Early Termination of a Session . . . . . . . . . . . . . . 65 52
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 66 54
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67 55
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 67 55
     13.2. Informative References . . . . . . . . . . . . . . . . . . 68
   Appendix A.  IP Address Configuration  . . . . . . . . . . . . . . 70 55
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 57
   Intellectual Property and Copyright Statements . . . . . . . . . . 75 59

1.  Introduction

   Providing secure network access service requires access control based
   on the authentication and authorization of the clients and the access
   networks.  Client-to-network authentication provides parameters that
   are needed to police the traffic flow through the enforcement points.
   A protocol is needed to carry authentication methods between the
   client and the access network.

   Currently there is no standard network-layer solution for
   authenticating clients for network access.  Appendix A of [RFC4058]
   describes the problem statement that led to the development of PANA.

   Scope of this work

   Scope of this work is identified as designing a link-layer agnostic network layer
   transport for network access authentication methods.  The Extensible
   Authentication Protocol (EAP) [RFC3748] provides such authentication
   methods.  In other words, PANA will carry EAP which can carry various
   authentication methods.  By the virtue of enabling transport of EAP
   above IP, any authentication method that can be carried as an EAP
   method is made available to PANA and hence to any link-layer
   technology.  There is a clear division of labor between PANA (an EAP
   lower layer), EAP and EAP methods as described in [RFC3748].

   Various environments and usage models for PANA are identified in
   Appendix A of [RFC4058].  Potential security threats for network-
   layer
   network-layer access authentication protocol are discussed in
   [RFC4016].  These have been essential in defining the requirements
   [RFC4058] on the PANA protocol.  Note that some of these requirements
   are imposed by the chosen payload, EAP [RFC3748].

   There are components that are part of a complete secure network
   access solution but are outside of the PANA protocol specification,
   including IP address configuration, authentication method choice,
   filter rule installation, data traffic protection,
   PAA-EP protocol protocol, and PAA discovery.  PANA authentication output is
   used for creating access control filters.  These components except for IP address
   configuration are
   described in separate documents (see [I-D.ietf-
   pana-framework], [I-D.ietf-pana-framework],
   [I-D.ietf-pana-snmp] and [I-D.ietf-dhc-paa-option]).
   See Appendix A for the IP address configuration component.  The readers are
   recommended to go through read the PANA Framework document
   [I-D.ietf-pana-framework] prior to reading this protocol
   specification document.

1.1.  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  The key
   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in [RFC2119].

2.  Terminology

   PANA Client (PaC):

      The client side of the protocol that resides in the access device
      (e.g., laptop, PDA, etc.).  It is responsible for providing the
      credentials in order to prove its identity (authentication) for
      network access authorization.  The PaC and the EAP peer are co-
      located
      co-located in the same access device.

   PANA Authentication Agent (PAA):

      The protocol entity in the access network whose responsibility is
      to verify the credentials provided by a PANA client (PaC) and
      authorize network access to the device associated with the client
      and identified by a Device Identifier (DI). access device.  The PAA and the
      EAP authenticator (and optionally the EAP server) are co-located
      in the same node.  Note the authentication and authorization
      procedure can, according to the EAP model, be also be offloaded to
      the backend AAA infrastructure.

   PANA Session:

      A PANA session begins with the handshake between the PANA Client
      (PaC) and the PANA Authentication Agent (PAA), and terminates as a
      result of an authentication or liveness test failure, a message
      delivery failure after retransmissions reach maximum values,
      session lifetime expiration, or an explicit termination message.
      A fixed session identifier is maintained throughout a session.  A
      session cannot be shared across multiple network interfaces.  Only
      one device identifier of the PaC is allowed to be bound to a PANA
      session for simplicity.

   Session Lifetime:

      A duration that is associated with a PANA session.  For an
      established PANA session, the session lifetime is bound to the
      lifetime of the current authorization given to the PaC.  The
      session lifetime can be updated by a new round of EAP
      authentication before it expires.

   Session Identifier:

      This identifier is used to uniquely identify a PANA session on the
      PAA
      PaC and PaC.  It includes an identifier of the PAA, therefore it
      cannot be shared across multiple PAAs. PAA.  It is included in PANA messages to bind the
      message to a specific PANA session.  This bidirectional identifier
      is allocated by the PAA following the in handshake phase and freed when the
      session terminates.  The session identifier is assigned by the PAA
      and unique within the PAA during the lifetime of the session.

   PANA Security Association (PANA SA):

      A PANA security association is formed between the PaC and the PAA
      by sharing cryptographic keying material and associated context.
      The formed duplex security association is used to protect the
      bidirectional PANA signaling traffic between the PaC and the PAA.

   Device Identifier (DI):

      The identifier used by the network as a handle to control and
      police the network access of a device.  Depending on the access
      technology, this identifier may contain an address that is carried
      in protocol headers (e.g., IP or link-layer address), or a locally
      significant identifier that is made available by the local
      protocol stack (e.g., circuit id, PPP interface id) of a connected
      device.

   Enforcement Point (EP):

      A node on the access network where per-packet enforcement policies
      (i.e., filters) are applied on the inbound and outbound traffic of
      access devices.  Information such as the DI and (optionally)
      cryptographic keys are provided by the PAA per client for
      generating filters on the EP.  The EP and the PAA may be co-located.

   Network Access Provider (NAP):

      A service provider that provides physical  EPs should
      prevent data traffic from and link-layer
      connectivity to an access network it manages.

   MSK: any unauthorized client unless
      it's either PANA or one of the other allowed traffic types (e.g.,
      ARP, IPv6 neighbor discovery, DHCP, etc.).  Detailed enforcement
      policies may be specified in deployment-specific PANA
      applicability documents.

   Master Session Key (MSK):

      A key derived by the EAP peer and the EAP server and transported
      to the EAP authenticator [RFC3748].

   For additional terminology definitions see the PANA framework
   document [I-D.ietf-pana-framework].

3.  Protocol Overview

   The PANA protocol is run between a client (PaC) and a server (PAA) in
   order to perform authentication and authorization for the network
   access service.

   The protocol messaging consists of a series of request and responses,
   some of which may be initiated by either end.  Each message can carry
   zero or more AVPs within the payload.  The main payload of PANA is
   EAP which performs authentication.  PANA helps the PaC and PAA
   establish an EAP session.

   PANA is a UDP-based protocol.  It has its own retransmission
   mechanism to reliably deliver messages.

   PANA messages are sent between the PaC and PAA as part of a PANA
   session.  A PANA session consists of distinct phases:

   o  Handshake phase: This is the phase that initiates a new PANA
      session.  The handshake phase can be triggered by both the PaC and
      the PAA.

   o  Authentication and authorization phase: Immediately following the
      handshake phase is the EAP execution between the PAA and PaC.  The
      EAP payload (which carry an EAP method inside) is what is used for
      authentication.  The PAA conveys the result of authentication and
      authorization to the PaC at the end of this phase.

   o  Access phase: After a successful authentication and authorization
      the host gains access to the network and can send and receive IP
      data traffic through the EP(s).  At any time during this phase,
      the PaC and PAA may optionally send PANA ping messages to test
      liveness of the PANA session on the peer.

   o  Re-authentication phase: During the access phase, the PAA must
      initiate re-authentication before the PANA session lifetime
      expires.  EAP is carried by PANA to perform authentication.  This
      phase may be optionally triggered by both the PaC and the PAA
      without any respect to the session lifetime.  The session moves to
      this phase from the access phase, and returns back there upon
      successful re-authentication.

   o  Termination phase: The PaC or PAA may choose to discontinue the
      access service at any time.  An explicit disconnect message can be
      sent by either end.  If either the PaC or the PAA disconnects
      without engaging in termination messaging, it is expected that
      either the expiration of a finite session lifetime or failed
      liveness tests would clean up the session at the other end.

     PaC  PAA    Message
   -----------------------------------------------------
   // Handshake phase
      ----->     PANA-Client-Initiation
      <-----     PANA-Start-Request
      ----->     PANA-Start-Answer

   // Authentication and authorization phase
      <-----     PANA-Auth-Request /* EAP Request */
      ----->     PANA-Auth-Answer
      ----->     PANA-Auth-Request /* EAP Response */
      <-----     PANA-Auth-Answer
      <-----     PANA-Bind-Request /* EAP Success */
      ----->     PANA-Bind-Answer

   // Access phase (IP data traffic allowed)
      <-----     PANA-Ping-Request
      ----->     PANA-Ping-Answer

   // Termination phase
      ----->     PANA-Termination-Request
      <-----     PANA-Termination-Answer

           Figure 1: Illustration of PANA messages in a session

   Note that depending on the environment and deployment the protocol
   flow depicted in Figure 1 can be abbreviated (An unsolicited PANA-
   Start-Request
   PANA-Start-Request message can be sent without
   PANA-Client-Initiation, EAP responses can be piggybacked on the
   PANA-Auth-Answers, and PANA-Ping and PANA-Termination usage is
   optional).

   Cryptographic protection of messages between the PaC and PAA is
   possible as soon as EAP in conjunction with the EAP method exports a
   shared key.  That shared key is used to create a PANA SA.  The PANA
   SA helps generate per-message authentication codes that provide
   integrity protection and authentication.

   Throughout the lifetime of a session, various problems found with the
   incoming messages can generate a PANA error message sent in response.

4.  Protocol Details

   The following sections explain in detail the various phases of a PANA
   session.

4.1.  Transport Layer

   PANA uses UDP as its transport layer protocol.  The UDP port number
   is To Be Assigned by IANA.  All messages are always unicast.

4.2.  High-Level Attribute-Value Pair Description

   The payload of any PANA message consists of zero or more AVPs
   (Attribute Value Pairs).  The subsequent sections refer to these
   AVPs, therefore the list of AVPs are provided with a brief
   description before more extensive descriptions are included later in
   the document (see Section 8).

   o  Algorithm AVP: contains a pseudo-random function and an integrity
      algorithm.

   o  AUTH AVP: contains a Message Authentication Code that integrity
      protects the PANA message.

   o  Cookie AVP: contains a random value that is generated by the PAA
      according to [RFC4086] and used for making the handshake phase
      robust against blind resource consumption DoS attacks.

   o  Device-Id AVP: contains a device identifier (link-layer address or
      an IP address) of the PaC or an EP.

   o  EAP  EAP AVP: contains an EAP PDU.

   o  Failed-AVP: contains an offending AVP that caused a failure.

   o  Key-Id AVP: contains an MSK identifier.

   o  Protection-Capability  Failed-Message-Header AVP: contains the type header of per-packet
      protection (link-layer vs. network-layer) when an offending
      message that caused a cryptographic
      mechanism should be enabled after PANA authentication. failure.

   o  NAP-Information AVP, ISP-Information  Key-Id AVP: contains the identifier
      of a NAP and an ISP, respectively. MSK identifier.

   o  Nonce AVP: contains a randomly chosen value [RFC4086] that is used
      in cryptographic key computations.

   o  Notification AVP: contains a displayable message.

   o  Provider-Identifier AVP: contains the identifier of a NAP or an
      ISP.

   o  PPAC AVP: Post-PANA-Address-Configuration AVP.  Used to indicate
      the available/chosen IP address configuration methods that can be
      used by the PaC after successful PANA authentication.

   o  Provider-Name AVP: contains a name of a NAP or an ISP.

   o  Result-Code AVP: contains information about the protocol execution
      results.

   o  Session-Id AVP: contains the PANA session identifier value.

   o  Session-Lifetime AVP: contains the duration of authorized access.

   o  Termination-Cause AVP: contains the reason of session termination.

4.3.  Handshake Phase

   The handshake phase can be initiated by either the PaC or the PAA.

   PaC-initiated Handshake:

      When the PaC initiates the handshake phase, it sends a PANA-
      Client-Initiation
      PANA-Client-Initiation message to the PAA.  When the PaC is not
      configured with an IP address of the PAA before initiating the
      handshake phase, DHCP [I-D.ietf-dhc-paa-option] is used as the
      default method for dynamically configuring the IP address of the
      PAA.  Alternative methods for dynamically discoverying discovering the IP
      address of the PAA may be used for PaC-initiated handshake but
      they are outside the scope of this specification.  The PAA that
      receives the PANA-Client-Initiation message MUST respond with a
      PANA-Start-Request message sent to the PaC.

   PAA-initiated Handshake:

      When the PAA knows the IP address of the PaC, it MAY send an
      unsolicited PANA-Start-Request to the PaC.  The details of how PAA
      can learn the IP address of the PaC are outside the scope of this
      specificaiton.
      specification.

   A session identifier for the session is assigned by the PAA in the
   handshake phase and carried in the PANA-Start-Request message.  The
   same session identifier MUST be carried in the subsequent messages
   exchanged between the PAA and PaC throughout the session.

   When the PaC receives a PANA-Start-Request message from a PAA, it
   responds with a PANA-Start-Answer message if it wishes to enter the
   authentication and authorization phase.

   A PANA-Start-Request message MAY carry a Cookie AVP that contains a
   random value generated by the PAA.

   The random value is referred to
   as a cookie.  The cookie is used for preventing the PAA from resource
   consumption DoS attacks by blind attackers which bombard MAY limit the PAA with rate it processes incoming
   PANA-Client-Initiation messages.  By relying on a cookie mechanism
   the PAA can avoid per-PaC state creation until after the PaC can
   produce the same cookie in its PANA-Start-Answer message.  In order
   to do that, the cookie MUST

   An Algorithm AVP MAY be computed included in such a way that it does
   not require any per-session state maintenance on the PAA in order to
   verify the cookie returned in the PANA-Start-Answer message.  The
   handshake phase that takes advantage of cookies is called "stateless
   handshake".  The exact algorithms and syntax used by the PAA to
   generate cookies does not affect interoperability and hence is not
   specified here.  Additionally, the PAA MAY limit the rate it
   processes incoming PANA-Client-Initiation messages.

   When the PaC sends a PANA-Start-Answer message in response to a PANA-
   Start-Request containing a Cookie AVP, the answer MUST contain a
   Cookie AVP with the cookie value copied from the request.

   When the PAA receives the PANA-Start-Answer message from the PaC, it
   verifies the cookie.  The cookie is considered as valid if the
   received cookie matches the send cookie.  If the match is verified,
   the protocol enters the authentication and authorization phase.
   Otherwise, the PAA MUST silently discard the received message.

   The initial EAP Request message MAY be optionally carried by the
   PANA-Start-Request (as opposed to by a later PANA-Auth-Request)
   message in order to reduce the number of round-trips.  This
   optimization SHOULD NOT be used if the PAA is desired to be stateless
   in the handshake phase since transmission of an EAP Request message
   creates a state at EAP layer.  See [RFC4137] for more information on
   the EAP state machine and the allocation of state information in the
   respective protocol steps.

   A Protection-Capability AVP, an Algorithm AVP and a Post-PANA-
   Address-Configuration (PPAC) AVP MAY be included in the PANA-Start-
   Request PANA-Start-Request in order
   to indicate required and available capabilities for the network
   access.  These AVPs  This AVP MAY be used by the PaC for assessing the capability
   match even before the authentication takes place.  Since these AVPs are this AVP is
   provided during the insecure handshake phase, there are certain
   security risks involved in using the provided information.  See
   Section 11 for further discussion on this.

   The initial EAP Request message MAY be carried by the
   PANA-Start-Request message (as oppose to by a later PANA-Auth-Request
   message) in order to reduce the number of round-trips.  If the
   initial EAP Request message is carried in the PANA-Start-
   Request PANA-Start-Request
   message, an EAP Response message MUST be carried in the PANA-
   Start-Answer
   PANA-Start-Answer message returned to the PAA.

   A Nonce AVP MUST be included in

   In order to prevent potential DoS attacks, the first PANA-Auth-Request and PANA-
   Auth-Answer messages in PAA MAY refrain from
   timeout-based retransmission of the authentication and authorization phase
   when stateless handshake is used, and in PANA-Start-Request and PANA-
   Start-Answer messages in this phase otherwise.

   A PANA-Start-Request message in stateless handshake MUST NOT be
   retransmitted as
   response to a PaC-initiated handshake.  For this voids the statelessness on the PAA.  Instead, reason, the PaC MUST
   retransmit the PANA-Client-Initiation message until it
   receives a PANA-Start-Request message, and retransmit the PANA-Start-
   Answer message until it receives a PANA-Auth-Request message.  The
   PaC can determine whether enters the PAA is using stateless handshake
   authentication and authorization phase by
   looking at the L-flag in receiving the PANA header.  The PANA-Start-Request first
   PANA-Auth-Request message MUST be retransmitted instead of from the PANA-Start-Answer
   message when stateful handshake is used (L-flag is not set). PAA.

   It is possible that both the PAA and the PaC initiate the handshake
   procedure at the same time, i.e., the PAA sends a PANA-Start-Request
   message while the PaC sends a PANA-Client-Initiation message.  To
   resolve the race condition, the PAA SHOULD silently discard the PANA-
   Client-Initiation
   PANA-Client-Initiation message received from the PaC after it has
   sent a PANA-Start-Request message with creating a state (i.e., L-flag is not
   set) for the PaC.  In this case the PAA will retransmit the PANA-
   Start-Request message based on a timer, if the PaC doesn't respond in
   time (the message was lost for example).  If the PAA had sent a PANA-
   Start-Request message without creating a state for the PaC (i.e.,
   L-flag is set), then it SHOULD answer to the PANA-Client-Initiation message.

   Figure 2 shows an example sequence for PaC-initiated handshake.

      PaC      PAA         Message(sequence number)[AVPs]
      ------------------------------------------------------
         ----->            PANA-Client-Initiation(0)
         <-----            PANA-Start-Request(x)[Cookie]            PANA-Start-Request(x)
         ----->            PANA-Start-Answer(x)[Cookie]            PANA-Start-Answer(x)
                           (continued to the authentication and
                            authorization phase)

       Figure 2: Example sequence for PaC-initiated handshake phase

4.4.  Authentication and Authorization Phase

   The main task of the authentication and authorization phase is to
   carry EAP messages between the PaC and the PAA.  EAP Request and
   Response messages are carried in PANA-Auth-Request messages.  PANA-
   Auth-Answer
   PANA-Auth-Answer messages are simply used to acknowledge receipt of
   the requests.  As an optimization, a PANA-Auth-Answer message MAY
   include the EAP Response message.  This optimization MAY not be used
   when it takes time to generate the EAP Response message (due to,
   e.g., intervention of human input), in which case returning an EAP-Auth-
   Answer
   PANA-Auth-Answer message without piggybacking an EAP Response message
   can avoid unnecessary retransmission of the PANA-Auth-Request
   message.  Another optimization allows optionally carrying the first
   EAP Request/
   Response Request/Response message in PANA-Start-Request/Answer message as
   described in Section 4.3.

   When stateless handshake was performed in the handshake phase, a

   A Nonce AVP MUST be included in the first PANA-Auth-Request and PANA-
   Auth-Answer
   PANA-Auth-Answer messages.

   The result of PANA authentication is carried in a PANA-Bind-Request
   message sent from the PAA to the PaC.  This message carries the EAP
   authentication result and the result of PANA authentication.  The
   PANA-Bind-Request message MUST be acknowledged with a PANA-Bind-
   Answer
   PANA-Bind-Answer (PBA) message.  Figure 3 shows an example sequence
   in the authentication and authorization phase.

 PaC      PAA  Message(sequence number)[AVPs]
 --------------------------------------------------------------------
               (continued from the handshake phase)
    <-----     PANA-Auth-Request(x+1)
                    [Session-Id, Nonce,     PANA-Auth-Request(x+1)[Nonce, EAP{Request}]
    ----->     PANA-Auth-Answer(x+1)     PANA-Auth-Answer(x+1)[Nonce] // No piggybacking EAP Response
                    [Session-Id, Nonce] Resp.
    ----->     PANA-Auth-Request(y)
                    [Session-Id, EAP{Response}]     PANA-Auth-Request(y)[EAP{Response}]
    <-----     PANA-Auth-Answer(y)
                    [Session-Id]
    <-----     PANA-Auth-Request(x+2)
                    [Session-Id, EAP{Request}]     PANA-Auth-Request(x+2)[EAP{Request}]
    ----->     PANA-Auth-Answer(x+2) // Piggybacking EAP Response
                    [Session-Id, EAP{Response}]     PANA-Auth-Answer(x+2)[EAP{Response}]
    <-----     PANA-Bind-Request(x+3)
                    [Session-Id, Result-Code,     PANA-Bind-Request(x+3)[Result-Code, EAP{Success}, Device-Id, Key-Id,
                                          Algorithm, Lifetime, Protection-Cap., PPAC, AUTH]
    ----->     PANA-Bind-Answer(x+3)
                    [Session-Id, Device-Id, Key-Id, PPAC,     PANA-Bind-Answer(x+3)[Key-Id, AUTH]

    Figure 3: Example sequence for the authentication and authorization
                                   phase

   When an EAP method that is capable of deriving keys is used during
   the authentication and authorization phase and the keys are
   successfully derived, the PANA message that carries the EAP Success
   message (i.e., a PANA-Bind-Request message) MUST contain a Key-Id AVP
   and an AUTH AVP, and an Algorithm AVP for the first derivation of
   keys in the session, and any subsequent message MUST contain an AUTH
   AVP.  An Algorithm AVP MUST NOT be contained in a PANA-Bind-Request
   message after the first derivation of keys in the session.

   The PANA-Bind-Request and

   EAP authentication can fail at a pass-through authenticator without
   sending an EAP Failure message [RFC4137].  When this occurs, the PANA-Bind-Answer PAA
   SHOULD send a PANA-Error-Request message exchange is
   also used for binding device identifiers of to the PaC and EP(s) to with using
   PANA_UNABLE_TO_COMPLY result code.  The PaC MUST NOT change its state
   unless the error message is secured by PANA SA.  To achieve this, if or lower-layer.  In any
   case, a Protection-Capability AVP more appropriate way is included
   in the PANA-Bind-Request message, the message MUST contain the device
   identifier in to rely on a Device-Id AVP for each EP.  Otherwise, if a
   Protection-Capability AVP is not included in the PANA-Bind-Request
   message, the message MUST contain timeout on the device identifier in PaC.

   There is a
   Device-Id AVP for each EP when case where EAP authentication succeeds with producing an
   EAP Success message but network access authorization fails due to,
   e.g., authorization rejected by a link-layer AAA or IP address is used as authorization locally
   rejected by the device identifier of PAA.  When this occurs, the PaC.  The PANA-Bind-Answer message PAA MUST
   contain the PaC's device identifier in send a Device-Id AVP when it is
   already presented
   PANA-Bind-Request with that of EP(s) in a result code PANA_AUTHORIZATION_REJECTED.  If
   an MSK is established between the request with using PaC and the
   same type of device identifier as contained in PAA by the request.  If time when
   the
   PANA-Bind-Answer EAP Success message sent from is generated by the PaC does not contain a
   Device-Id AVP with EAP server (this is the same device identifier type contained in
   case when the
   request, EAP method provides protected success indication), the PAA sends a PANA-Error-Request message
   PANA-Bind-Request and PANA-Bind-Answer messages MUST be protected
   with a
   PANA_MISSING_AVP result code, an AUTH AVP and wait for carry a PANA-Error-Answer
   message to terminate the session. Key-Id AVP.  The PANA-Bind-Request
   message with a PANA_SUCCESS result code MUST also contain a Protection-Capability carry an Algorithm AVP if link-layer or network-
   layer ciphering it is enabled after for the authentication and authorization
   phase. first
   derivation of keys in the session.  The PANA-Bind-Request message MAY also contain a Protection-
   Capability AVP to indicate if link-layer or network-layer ciphering
   should MSK and the PANA session MUST
   be enabled deleted immediately after the PANA-Bind message exchange.

4.5.  Access Phase

   Once the authentication and authorization phase.
   No link-layer phase or network-layer specific information is included in the Protection-Capability AVP.  It is assumed that
   re-authentication phase successfully completes, the PAA is aware
   of PaC gains access
   to the security capabilities of network and can send and receive IP data traffic through the access network.  The PANA
   protocol does not specify how
   EP(s) and the PANA SA and session enters the Protection-
   Capability AVP will access phase.  In this phase,
   PANA-Ping-Request and PANA-Ping-Answer messages can be used to provide per-packet protection for data
   traffic.  When
   testing the PaC does not support liveness of the protection capability
   indicated in PANA session on the Protection-Capability AVP, PANA peer.  Both the
   PaC MUST and the PAA are allowed to send a PANA-
   Error-Request PANA-Ping-Request message with a PANA_PROTECTION_CAPABILITY_UNSUPPORTED
   result code and terminate to
   the PANA session.

   Additionally, communicating peer whenever they need to make sure the PANA-Bind-Request message with a PANA_SUCCESS
   result code MUST include a Post-PANA-Address-Configuration (PPAC)
   AVP, which helps
   availability of the PAA to inform session on the PaC about whether a new IP
   address MUST be configured peer and expect the available methods peer to do so.  In
   this case, the PaC MUST include return
   a PPAC PANA-Ping-Answer message.  Both PANA-Ping-Request and
   PANA-Ping-Answer messages MUST be protected with an AUTH AVP in the PANA-Bind-Answer
   message in order to indicate its choice of method when there is a
   match between the methods offered by
   PANA SA is available.

   Implementations MUST limit the PAA rate of performing this test.  The PaC
   and the methods
   available PAA can handle rate limitation on the PaC.  When there their own, they do not have
   to perform any coordination with each other.  There is no match, negotiation
   of timers for this purpose.  Additionally, an implementation MAY
   rate-limit processing the PaC MUST send a
   PANA-Error-Request message with a PANA_PPAC_CAPABILITY_UNSUPPORTED
   result code incoming PANA-Ping-Requests.

   Figure 4 and terminate the PANA session.

   EAP authentication can fail at a pass-through authenticator without
   sending an EAP Failure message [RFC4137].  When this occurs, Figure 5 show liveness tests as they are initiated by
   the PAA
   SHOULD send a PANA-Error-Request message to PaC and the PAA respectively.

   PaC with using
   PANA_UNABLE_TO_COMPLY result code.  The      PAA     Message(sequence number)[AVPs]
   ------------------------------------------------------
      ----->        PANA-Ping-Request(q)[AUTH]
      <-----        PANA-Ping-Answer(q)[AUTH]

        Figure 4: Example sequence for PaC-initiated liveness test

   PaC MUST NOT change its state
   unless the error message is secured by      PAA     Message(sequence number)[AVPs]
   ------------------------------------------------------
      <-----        PANA-Ping-Request(p)[AUTH]
      ----->        PANA-Ping-Answer(p)[AUTH]

        Figure 5: Example sequence for PAA-initiated liveness test

4.6.  Re-authentication Phase

   The PANA or lower-layer.  In any
   case, a more appropriate way is session in the access phase can enter the re-authentication
   phase to rely on a timeout on extend the PaC.

   There current session lifetime by re-executing EAP.
   Once the re-authentication phase successfully completes, the session
   re-enters the access phase.  Otherwise, the session is deleted.

   When the PaC wants to initiate re-authentication, it sends a case where EAP authentication succeeds with producing an
   EAP Success
   PANA-Reauth-Request message but network access authorization fails due to,
   e.g., authorization rejected by a AAA or authorization locally
   rejected by to the PAA.  When this occurs, the PAA  This message MUST send a PANA-
   Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. contain
   the session identifier assigned to the session being
   re-authenticated.  If the PAA already has an
   MSK is established between PANA session
   for the PaC and with the PAA matching session identifier, it MUST first
   respond with a PANA-Reauth-Answer message, followed by the time when the
   EAP Success a
   PANA-Auth-Request message is generated by the that starts a new EAP server (this is the case
   when authentication.  If
   the EAP method provides protected success indication), PAA cannot identify the PANA-
   Bind-Request and PANA-Bind-Answer messages session, it MUST be protected with an
   AUTH silently discard the
   message.  A Nonce AVP and carry a Key-Id AVP.  The PANA-Bind-Request message MUST
   also carry an Algorithm AVP if it is for be included in the first derivation of keys PANA-Auth-Request
   and PANA-Auth-Answer messages in the session. re-authentication phase.

   The MSK and the PANA session MUST be deleted
   immediately after the PANA-Bind message exchange.

4.5.  Access Phase

   Once the authentication and authorization phase or the re-
   authentication phase successfully completes, the PaC gains access to may receive a PANA-Auth-Request before receiving the network and answer
   to its outstanding PANA-Reauth-Request.  This condition can send and receive IP data traffic through arise due
   to packet re-ordering or a race condition between the
   EP(s) PaC and PAA
   when they both attempt to engage in re-authentication.  The PaC MUST
   keep discarding the PANA session enters received PANA-Auth-Requests until it receives the access phase.  In this phase,
   PANA-Ping-Request and PANA-Ping-Answer messages can be used for
   testing
   answer to its request.

   When the liveness of PAA initiates re-authentication, it sends a
   PANA-Auth-Request message containing the PANA session on the PANA peer.  Both identifier for the
   PaC and the PAA are allowed to send a PANA-Ping-Request message to enter the communicating peer whenever they need to make sure re-authentication phase.  The PAA SHOULD initiate
   EAP re-authentication before the
   availability current session lifetime expires.

   Re-authentication of the an on-going PANA session on the peer and expect MUST maintain the peer to return
   a PANA-Ping-Answer message.  Both PANA-Ping-Request
   existing sequence numbers.

   For any re-authentication, if there is an established PANA SA,
   PANA-Reauth-Request, PANA-Reauth-Answer, PANA-Auth-Request and PANA-Ping-
   Answer
   PANA-Auth-Answer messages MUST be protected with by adding an AUTH AVP when a PANA SA is
   available.

   Implementations MUST limit the rate of performing this test.  The PaC
   and the PAA can handle rate limitation on their own, they do not have to perform any coordination with
   each other.  There is no negotiation
   of timers for this purpose.  Additionally, an implementation MAY
   rate-limit processing the incoming PANA-Ping-Requests.

   Figure 4 and Figure 5 show liveness tests as they are initiated by
   the PaC and the PAA respectively. message.

 PaC      PAA  Message(sequence number)[AVPs]
 ------------------------------------------------------
    ----->        PANA-Ping-Request(q)[Session-Id,     PANA-Reauth-Request(q)[AUTH]
    <-----     PANA-Reauth-Answer(q)[AUTH]
    <-----     PANA-Auth-Request(p)[EAP{Request}, AUTH]
    ----->     PANA-Auth-Answer(p)[AUTH]   // No piggybacking EAP Resp.
    ----->     PANA-Auth-Request(q+1)[EAP{Response}, AUTH]
    <-----        PANA-Ping-Answer(q)[Session-Id,     PANA-Auth-Answer(q+1)[AUTH] // No piggybacking EAP Resp.
    <-----     PANA-Auth-Request(p+1)[EAP{Request}, AUTH]
    ----->     PANA-Auth-Answer(p+1)[EAP{Response}, AUTH]

   Figure 4: Example sequence for PaC-initiated liveness test

   PaC      PAA     Message(sequence number)[AVPs]
   ------------------------------------------------------
    <-----        PANA-Ping-Request(p)[Session-Id,     PANA-Bind-Request(p+2)[Result-Code, EAP{Success}, Key-Id,
                                           Algorithm, Lifetime, AUTH]
    ----->        PANA-Ping-Answer(p)[Session-Id,     PANA-Bind-Answer(p+2)[Key-Id, AUTH]

   Figure 5: 6: Example sequence for PAA-initiated liveness test

4.6.  Re-authentication Phase

   The PANA session in the access phase can enter the re-authentication phase to extend the current session lifetime initiated
                                  by re-executing EAP.
   Once the re-authentication phase successfully completes, the session
   re-enters the access phase.  Otherwise, the PaC

4.7.  Termination Phase

   A procedure for explicitly terminating a PANA session is deleted.

   When can be
   initiated either from the PaC wants to initiate re-authentication, it sends a PANA-
   Reauth-Request message to (i.e., disconnect indication) or from
   the PAA.  This PAA (i.e., session revocation).  The PANA-Termination-Request and
   PANA-Termination-Answer message MUST contain a
   Session-Id AVP which is exchanges are used for identifying the PANA disconnect
   indication and session on the
   PAA.  If revocation procedures.

   The reason for termination is indicated in the PAA already has Termination-Cause AVP.
   When there is an established PANA session for SA between the PaC
   with and the matching session identifier, it PAA, all
   messages exchanged during the termination phase MUST first respond be protected
   with a
   PANA-Reauth-Answer message, followed by a PANA-Auth-Request that
   starts a new EAP authentication.  If an AUTH AVP.  When the PAA cannot identify sender of the
   session, it MAY respond with a PANA-Error-Request PANA-Termination-Request
   message with a
   result code PANA_UNKNOWN_SESSION_ID.  Transmission of this error
   request is made optional in case this behavior is leveraged for a DoS
   attack on the PAA.

   The PaC may receive a PANA-Auth-Request before receiving the answer
   to its outstanding PANA-Reauth-Request.  This condition can arise due
   to packet re-ordering or a race condition between the PaC and PAA
   when they both attempt to engage in re-authentication.  The PaC MUST
   keep discarding the received PANA-Auth-Requests until it receives the
   answer to its request.

   When the PAA initiates re-authentication, it sends a PANA-Auth-
   Request message containing the session identifier valid acknowledgment, all states maintained for
   the PaC to
   enter the re-authentication phase.  The PAA SHOULD initiate EAP re-
   authentication before the current session lifetime expires.

   Re-authentication of an on-going PANA session MUST maintain the
   existing sequence numbers.

   For any re-authentication, if there is an established PANA SA, PANA-
   Auth-Request and PANA-Auth-Answer messages MUST be protected by
   adding a MAC AVP to each message.  If a network selection (see
   Section 5.10 was made during the handshake phase, any subsequent EAP
   authentication MUST be performed with the already selected ISP and
   NAP. deleted immediately.

   PaC      PAA     Message(sequence number)[AVPs]
   ------------------------------------------------------
      ----->     PANA-Reauth-Request(q)
                    [Session-Id, AUTH]
      <-----     PANA-Reauth-Answer(q)
                    [Session-Id, AUTH]
      <-----     PANA-Auth-Request(p)
                    [Session-Id, EAP{Request}, AUTH]
      ----->     PANA-Auth-Answer(p)   // No piggybacking EAP Response
                    [Session-Id, AUTH]
      ----->     PANA-Auth-Request(q+1)
                    [Session-Id, EAP{Response}, AUTH]
      <-----     PANA-Auth-Answer(q+1) // No piggybacking EAP Response
                    [Session-Id, AUTH]
      <-----     PANA-Auth-Request(p+1)
                    [Session-Id, EAP{Request}, AUTH]
      ----->     PANA-Auth-Answer(p+1) // Piggybacking EAP Response
                    [Session-Id, EAP{Response}, AUTH]        PANA-Termination-Request(q)[AUTH]
      <-----     PANA-Bind-Request(p+2)
                    [Session-Id, Result-Code, EAP{Success},
                     Device-Id, Key-Id, Algorithm,
                     Lifetime, Protection-Cap., PPAC, AUTH]
      ----->     PANA-Bind-Answer(p+2)
                    [Session-Id, Device-Id, Key-Id, PPAC, AUTH]        PANA-Termination-Answer(q)[AUTH]

   Figure 6: 7: Example sequence for the re-authentication termination phase initiated triggered by PaC

4.7.  Termination Phase

   A procedure for explicitly terminating a PANA session can be
   initiated either from the PaC (i.e., disconnect indication) or from
   the PAA (i.e., session revocation).  The PANA-Termination-Request and
   PANA-Termination-Answer message exchanges are used for disconnect
   indication and session revocation procedures.

   The reason for termination is indicated in the Termination-Cause AVP.
   When there is an established PANA SA between the PaC and the PAA, all
   messages exchanged during the termination phase MUST be protected
   with an AUTH AVP.  When the sender of the PANA-Termination-Request
   message receives a valid acknowledgment, all states maintained for
   the PANA session MUST be deleted immediately.

   PaC      PAA     Message(sequence number)[AVPs]
   ------------------------------------------------------
      ----->        PANA-Termination-Request(q)[Session-Id, AUTH]
      <-----        PANA-Termination-Answer(q)[Session-Id, AUTH]

   Figure 7: Example sequence for the termination phase triggered by PaC

5.  Processing Rules

5.1.  Fragmentation

5.  Processing Rules

5.1.  Fragmentation

   PANA does not provide fragmentation of PANA messages.  Instead, it
   relies on fragmentation provided by EAP methods and IP layer when
   needed.

5.2.  Sequence Number and Retransmission

   PANA uses sequence numbers to provide ordered and reliable delivery
   of messages.

   The PaC and PAA maintain two sequence numbers: the next one to be
   used for a request it initiates and the next one it expects to see in
   a request from the other end.  These sequence numbers are 32-bit
   unsigned numbers.  They are monotonically incremented by 1 as new
   requests are generated and received, and wrapped to zero on the next
   message after 2^32-1.  Answers always contain the same sequence
   number as the corresponding request.  Retransmissions reuse the
   sequence number contained in the original packet.

   The initial sequence numbers (ISN) are randomly picked by the PaC and
   PAA as they send their very first request messages.  PANA-Client-
   Initiation
   PANA-Client-Initiation message carries sequence number 0.

   When a request message is received, it is considered valid in terms
   of sequence numbers if and only if its sequence number matches the
   expected value.  This check does not apply to the PANA-Client-
   Initiation,
   PANA-Client-Initiation and PANA-Start-Request messages.

   When an answer message is received, it is considered valid in terms
   of sequence numbers if and only if its sequence number matches that
   of the currently outstanding request.  A peer can only have one
   outstanding request at a time.

   PANA request messages are retransmitted based on a timer until a
   response is received (in which case the retransmission timer is
   stopped) or the number of retransmission reaches the maximum value
   (in which case the PANA session MUST be deleted immediately).

   The retransmission timers SHOULD be calculated as described in
   Section 9 unless a given deployment chooses to use its own
   retransmission timers optimized for the underlying link-layer
   characteristics.

   The PaC and PAA MUST respond to duplicate requests as long as the
   responding rate does not exceed a certain threshold value.  The last
   transmitted answer MAY be cached in case it is not received by the
   peer and that generates a retransmission of the last request.  When
   available, the cached answer can be used instead of fully processing
   the retransmitted request and forming a new answer from scratch.

   PANA MUST NOT generate EAP message duplication.  EAP payload of a
   retransmitted PANA message MUST NOT be passed to the EAP layer.

5.3.  PANA Security Association

   A PANA SA is created as an attribute of a PANA session when EAP
   authentication succeeds with a creation of an MSK.  A PANA SA is not
   created when the PANA authentication fails or no MSK is produced by
   any EAP authentication method.  When a new MSK is derived in the PANA
   re-authentication phase, any key derived from the old MSK MUST be
   updated to a new one that is derived from the new MSK.  In order to
   distinguish the new MSK from old ones, one Key-Id AVP MUST be carried
   in PANA-Bind-Request and PANA-Bind-Answer messages at the end of the
   EAP authentication which resulted in deriving a new MSK.  The Key-Id
   AVP is of type Unsigned32 and MUST contain a value that uniquely
   identifies the MSK within the PANA session.  The PANA-Bind-Answer
   message sent in response to a PANA-Bind-Request message with a Key-Id
   AVP MUST contain a Key-Id AVP with the same MSK identifier carried in
   the request.  PANA-Bind-Request and PANA-Bind-Answer messages with a
   Key-Id AVP MUST also carry an AUTH AVP whose value is computed by
   using the new PANA_AUTH_KEY derived from the new MSK.  Although the
   specification does not mandate a particular method for calculation of
   the Key-Id AVP value, a simple method is to use monotonically
   increasing numbers.

   The PANA session lifetime is bounded by the authorization lifetime
   granted by the authentication server (same as the MSK lifetime).  The
   lifetime of the PANA SA (hence the PANA_AUTH_KEY) is the same as the
   lifetime of the PANA session.  The created PANA SA is deleted when
   the corresponding PANA session is deleted.

   PANA SA attributes as well as PANA session attributes are listed
   below:

   PANA Session attributes:

      *  Session-Id

      *  Device-Id of PaC  Session Identifier

      *  IP address and UDP port number of the PaC.

      *  IP address and UDP port number of the PAA

      *  List of device identifiers of EPs

      *  Sequence number of the last transmitted request

      *  Sequence number of the last received request
      *  Last transmitted message payload

      *  Retransmission interval

      *  Session lifetime

      *  Protection-Capability

      *  PANA SA attributes

   PANA SA attributes:

      *  Nonce generated by PaC (PaC_nonce)

      *  Nonce generated by PAA (PAA_nonce)

      *  MSK

      *  MSK Identifier

      *  PANA_AUTH_KEY

      *  Pseudo-random function

      *  Integrity algorithm

   The PANA_AUTH_KEY is derived from the available MSK and it is used to
   integrity protect PANA messages.  The PANA_AUTH_KEY is computed in
   the following way:

    PANA_AUTH_KEY = prf+(MSK, PaC_nonce | PAA_nonce | Session-ID) PaC_nonce|PAA_nonce|Session_ID|Key_ID)

   where the prf+ function is defined in IKEv2 [RFC4306].  The pseudo-
   random
   pseudo-random function to be used for the prf+ function is specified
   in the Algorithm AVP in a PANA-Bind-Request message.  The length of
   PANA_AUTH_KEY depends on the integrity algorithm in use.  See
   Section 5.4 for the detailed usage of the PANA_AUTH_KEY.  PaC_nonce
   and PAA_nonce are values of the Nonce AVP carried in the first
   PANA-Auth-Answer and PANA-Auth-Request messages in the authentication
   and authorization phase or the re-authentication phase, respectively.
   Session_ID is the session identifier of the session.  Key_ID is the
   value of the Key-ID AVP.

5.4.  Message Authentication

   A PANA message can contain an AUTH AVP for cryptographically
   protecting the message.

   When an AUTH AVP is included in a PANA message, the value field of
   the AUTH AVP is calculated by using the PANA_AUTH_KEY in the
   following way:

      AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU)

   where PANA_PDU is the PANA message including the PANA header, with
   the AUTH AVP value field first initialized to 0.  PANA_AUTH_HASH
   represents the integrity algorithm specified in the Algorithm AVP in
   a PANA-Bind-Request message.  The PaC and PAA MUST use the same
   integrity algorithm to calculate an AUTH AVP they originate and
   receive.  The algorithm is determined by the PAA.  When the PaC does
   not support the integrity algorithm specified in the PANA-Bind-
   Request
   PANA-Bind-Request message, it MUST silently discard the message.

5.5.  Message Validity Check

   When a PANA message is received, the message is considered to be
   invalid at least when one of the following conditions are not met:

   o  Each field in the message header contains a valid value including
      sequence number, message length, message type, version number,
      flags, session identifier, etc.

   o  The message type is one of the expected types in the current
      state.  Specifically the following messages are unexpected and
      invalid:

      *  In the handshake phase:

         +  PANA-Termination-Request and PANA-Ping-Request.

         +  PANA-Bind-Request.

         +  PANA-Update-Request.

         +  PANA-Reauth-Request.

         +  PANA-Error-Request.

      *  In the authentication and authorization phase and the re-
         authentication
         re-authentication phase:

         +  PANA-Client-Initiation.

         +  PANA-Update-Request.

         +  PANA-Start-Request after a PaC receives the first valid
            PANA-Auth-Request.

         +  PANA-Termination-Request before the PaC receives the first
            successful PANA-Bind-Request.

      *  In the access phase:

         +  PANA-Start-Request as well as a non-duplicate PANA-Bind-
            Request.
            PANA-Bind-Request.

         +  PANA-Client-Initiation.

      *  In the termination phase:

         +  PANA-Client-Initiation.

         +  All requests but PANA-Termination-Request.

   o  The message payload contains a valid set of AVPs allowed for the
      message type and there is no missing AVP that needs to be included
      in the payload and no AVP, which needs to be at a fixed position,
      is included in a position different from this fixed position.

   o  Each AVP is decoded correctly.

   o  When an AUTH AVP is included, the AVP value matches the hash value
      computed against the received message.

   o  When a Device-Id AVP is included, the AVP is valid if the device
      identifier type contained in the AVP is supported (check performed
      by both the PaC and the PAA) and is the requested one (check
      performed by the PAA only).  Note that a Device-Id AVP carries the
      device identifier of the PaC in messages from the PaC to the PAA
      and the device identifier(s) of the EP(s) in messages from the PAA
      to the PaC.

   Invalid messages MUST be discarded in order to provide robustness
   against DoS attacks.  In addition, an error notification message MAY
   be returned to the sender.  See Section 5.11 5.8 for details.

5.6.  PaC-EP-Master-Key

   As described in Section 4.4, use of a cryptographic filtering
   mechanism is indicated by inclusion of a Protection-Capability AVP  PaC Updating its IP Address

   A PaC's IP address used for PANA can change in certain situations,
   e.g., when the PANA-Bind-Request message in PaC moves from one IP link to another within the authentication and authorization
   phase. same
   PAA's realm.  In this case, a PaC-EP-Master-Key is derived from order to maintain the MSK for
   each EP and used by a secure association protocol for bootstrapping
   link-layer or IPsec ciphering between PANA session, the PaC and EP.  The PaC-EP-
   Master-Key derivation algorithm is defined as follows.

   PaC-EP-Master-Key = The first 64 octets PAA needs to
   be notified about the change of
                       prf+(MSK, "PaC-EP master key" |
                            Session ID | Key-ID | EP-Device-Id)

   The prf+ function is defined in IKEv2 [RFC4306].  The pseudo-random
   function PaC address.

   After the PaC has changed its IP address used for PANA, it MUST send
   a PANA-Update-Request message to the prf+ function is specified in PAA.  The PAA MUST update the Algorithm AVP
   PANA session with the new PaC address carried in a PANA-Bind-Request message.

   EP-Device-Id is the Data Source Address
   field of the Device-Id AVP for the
   corresponding EP.

5.7.  Device ID Choice

   The device identifier used in the context of PANA can be an IP
   address, header and return a MAC address, or PANA-Update-Answer message.  If
   there is an identifier that may not established PANA SA, both PANA-Update-Request and
   PANA-Update-Answer messages MUST be carried in
   data packets but has local significance in identifying a connected
   device (e.g., circuit id, PPP interface id). protected with an AUTH AVP.

5.7.  Session Lifetime

   The last type of
   identifiers (i.e., locally-significant identifiers) are commonly used
   in point-to-point links where MAC addresses are not available authentication and
   lower-layers are already physically or cryptographically secured.
   The locally-significant identifiers are used locally to associate authorization phase determines the PANA sessions with
   session lifetime when the local interfaces and are not meant to be
   exchanged with the peers.

   It is assumed that the PAA knows the link type and the security
   mechanisms being provided or required on the access network based on
   configuration by access authorization succeeds.  The
   Session-Lifetime AVP MAY be optionally included in the network administrator.  For example, one network
   administrator might want
   PANA-Bind-Request message to use IPsec for securing inform the network access
   while another one (for a different network) might rely on physical
   security.

   When IPsec-based security [I-D.ietf-pana-ipsec] is PaC about the choice valid lifetime
   of
   access control, the PAA PANA session.  It MUST provide IP addresses as device
   identifiers of EPs, and expect the PaC to provide its IP address in
   return.  Similarly, IP addresses are used as the device identifiers be ignored when included in other PANA
   messages.

   When the EPs are Session-Lifetime AVP is not on included in the same IP subnet as
   PANA-Bind-Request message then the PaC.

   In other cases, MAC addresses are used as device identifiers when
   they are available.

   If non-IPsec access control is enabled, and PaC has no knowledge about a MAC address PANA
   session limitation and must therefore conclude that the session is
   not
   available, locally-significant identifiers (e.g., as limited.

   The lifetime is a circuit id)
   MUST non-negotiable parameter that can be used as device identifiers.  Note that these identifiers are
   not exchanged within PANA messages.  Instead, peers rely on lower-
   layers to provide them along with received PANA messages.

5.8. by the
   PaC Updating its IP Address

   A PaC's IP address can change in certain situations.  For example,
   Appendix A describes a case in which a to manage PANA-related state.  The PaC replaces a pre-PANA
   address (PRPA - the IP address configured prior does not have to PANA) with a post- perform
   any actions when the lifetime expires, other than purging local
   state.  The PAA SHOULD initiate the PANA address (POPA - re-authentication phase
   before the new IP address configured after PANA, as
   required by some deployments).  In another situation a current session lifetime expires.

   The PaC may change
   its IP address used for PANA when it moves from one IP link to
   another within the same PAA's realm.  In order to maintain the PANA
   session, and the PAA needs MAY use information obtained outside PANA (e.g.,
   lower-layer indications) to be notified about expedite the change detection of PaC
   address.

   If the device identifier a disconnected
   peer.  Availability and reliability of such indications MAY depend on
   a specific link-layer or network topology and are therefore only
   hints.  A PANA peer SHOULD use the PaC is the IP address, it PANA-Ping message exchange to
   verify that a peer is, in fact, no longer alive, unless information
   obtained outside PANA is also
   subject being used to expedite the same change. detection of a
   disconnected peer.

   The PAA needs session lifetime parameter is not related to be notified about the
   change transmission of device identifier as well so that the PAA
   PANA-Ping-Request messages.  These messages can update the
   EPs.  If IPsec is be used between the PaC and for
   asynchronously verifying the EPs, an IKE [RFC2409]
   IKEv2 [RFC4306] or MOBIKE [I-D.ietf-mobike-protocol] run is needed
   following such a change.

   After liveness of the PaC has changed its IP address, it MUST peer.  The decision to
   send a PANA-Update-
   Request PANA-Ping-Request message to is taken locally and does not
   require coordination between the PAA.  If peers.

5.8.  Error Handling

   A PANA-Error-Request message MAY be sent by either the PaC has also changed its device
   identifier, the PANA-Update-Request message MUST include a Device-Id
   AVP containing or the new device identifier.  The PAA MUST update the
   when a badly formed PANA session with the new PaC address carried message is received or in the Source Address
   field case of the IP header and the new device identifier carried in the
   Device-Id AVP, and return a PANA-Update-Answer message. other
   errors.  The PANA-
   Update-Answer message receiver of this request MUST contain one or more Device-Id AVPs for respond with a
   PANA-Error-Answer message.

   An adversary might craft erroneous PANA messages to launch a Denial
   of Service attack.  Unless the
   EPs if PaC or the set PAA performs a
   rate-limitation of EPs serving the generated PANA-Error-Request messages it may
   be overburdened by responding to bogus messages.  Note that a
   PANA-Error-Answer message that is sent in response to a
   PANA-Error-Request message does not require either the PaC has also changed. or the PAA
   to create a state.

   If there an error message is sent unprotected (i.e., without using an established PANA SA, both PANA-Update-Request and PANA-Update-
   Answer messages AUTH
   AVP) then the error message MUST be protected with an AUTH AVP.

5.9.  Session Lifetime

   The authentication and authorization phase determines processed such that the receiver
   does not change its state.

6.  Header Format

   This section defines message formats for PANA
   session lifetime when protocol.

6.1.  IP and UDP Headers

   Any PANA message is unicast between the network access authorization succeeds.  The
   Session-Lifetime AVP MAY be optionally included in PaC and the PANA-Bind-
   Request PAA.

   When the PANA message is sent in response to inform the PaC about a request, the valid lifetime UDP
   source and destination ports of the
   PANA session.  It response message MUST be ignored when included in copied
   from the destination and source ports of the request message,
   respectively.

   For other PANA
   messages.

   When messages, the Session-Lifetime AVP is not included in source port MUST be set to a value
   chosen by the PANA-Bind-
   Request message then sender and the PaC has no knowledge about a destination port MUST be set to the
   assigned PANA session
   limitation and must therefore conclude that port (To Be Assigned by IANA).

6.2.  PANA Message Header

   A summary of the session PANA message header format is not
   limited. shown below.  The lifetime is a non-negotiable parameter that can
   fields are transmitted in network byte order.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |   Reserved    |        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Flags             |         Message Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Session Identifier                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  AVPs ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Version

      This Version field MUST be used by the
   PaC set to manage PANA-related state.  The PaC does not have 1 to perform
   any actions when the lifetime expires, other than purging local
   state.  The PAA SHOULD initiate the indicate PANA re-authentication phase
   before the current session lifetime expires.

   The PaC Version 1.

   Reserved

      This 8-bit field is reserved for future use, and the PAA MAY use information obtained outside PANA (e.g.,
   lower-layer indications) MUST be set to expedite
      zero, and ignored by the detection of a disconnected
   peer.  Availability receiver.

   Message Length

      The Message Length field is two octets and reliability indicates the length of such indications MAY depend on
   a specific link-layer or network topology and are therefore only
   hints.  A PANA peer SHOULD use
      the PANA-Ping message exchange to
   verify that a peer is, in fact, no longer alive, unless information
   obtained outside PANA is being used to expedite message including the detection of a
   disconnected peer. header fields.

   Flags

      The session lifetime parameter Flags field is not related to the transmission of
   PANA-Ping-Request messages.  These messages can be used for
   asynchronously verifying the liveness of the peer. two octets.  The decision to
   send following bits are assigned:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R r r r r r r r r r r r r r r r|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      R(equest)

         If set, the message is a PANA-Ping-Request request.  If cleared, the message is taken locally
         an answer.

      r(eserved)

         These flag bits are reserved for future use, and does not
   require coordination between the peers.

5.10.  Network Selection

   The handshake phase allows the PaC MUST be set to learn identity of the NAP
         zero, and a
   list of ISPs that are available through ignored by the NAP. receiver.

   Message Type

      The PaC can not
   only learn the ISPs but also convey Message Type field is two octets, and is used in order to
      communicate the selected ISP explicitly
   during message type with the handshake phase. message.  The PAA 16-bit address
      space is assumed managed by IANA [ianaweb].

   Session Identifier

      This field contains a 32 bit session identifier.

   Sequence Number

      This field contains contains a 32 bit sequence number.

   AVPs

      AVPs are a method of encapsulating information relevant to be pre-configured
   with the
      PANA message.  See section Section 6.3 for more information on
      AVPs.

6.3.  AVP Header

   Each AVP of ISPs that type OctetString MUST be padded to align on a 32-bit
   boundary, while other AVP types align naturally.  A number of
   zero-valued bytes are served by added to the NAP.

   A PANA-Start-Request message sent from end of the PAA MAY contain zero or
   one NAP-Information AVP, and zero or more ISP-Information AVPs. AVP Data field till a
   word boundary is reached.  The
   PaC MAY indicate its choice length of ISP by including an ISP-Information
   AVP the padding is not reflected
   in the PANA-Start-Answer message. AVP Length field [RFC3588].

   The PaC MAY convey its ISP
   even when there is no ISP-Information fields in the AVP contained header are sent in network byte order.  The
   format of the PANA-
   Start-Request message. header is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AVP Code            |           AVP Flags           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Vendor-Id (opt)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+-+-+-+-+

   AVP Code

      The PaC can do AVP Code, together with the optional Vendor ID field,
      identifies attribute that when it follows.  If the V-bit is pre-configured
   with ISP information.

   In not set, the absence of an ISP explicitly selected
      Vendor ID is not present and conveyed by the PaC,
   ISP selection AVP Code refers to an IETF
      attribute.

   AVP Flags

      The AVP Flags field is typically performed based on two octets.  The following bits are
      assigned:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V M r r r r r r r r r r r r r r|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      V(endor)

         The 'V' bit, known as the client identifier
   (e.g., using Vendor-Specific bit, indicates
         whether the realm portion of an NAI carried optional Vendor-Id field is present in EAP method).  A
   backend AAA protocol (e.g., RADIUS) will run between the AAA client
   on the PAA and a AAA server in AVP
         header.  When set the AVP Code belongs to the selected ISP domain. specific vendor
         code address space.

      M(andatory)

         The PANA-based ISP selection mechanism dictates 'M' Bit, known as the next-hop AAA
   proxy on Mandatory bit, indicates whether
         support of the PAA. AVP is required.  If an AVP with the NAP requires all AAA traffic to go through
   its local AAA proxy, it may have to rely on a mechanism to relay 'M' bit set
         is received by the
   selected ISP information from PaC or PAA (AAA client) to the local AAA
   proxy.  The local AAA proxy can forward the AAA traffic to and either the
   selected ISP domain upon processing.  Further details, including how AVP or its value
         is unrecognized, the AAA client relays AAA routing information to message MUST be rejected and the AAA proxy, are
   outside receiver
         MUST send a PANA-Error-Request message.  If the scope of PANA.

   An alternative ISP selection mechanism is outlined in [RFC4284] which
   suggests advertising ISP information in-band with AVP was
         unrecognized the ongoing EAP
   method execution.  Deployments using PANA-Error-Request message result code MUST be
         PANA_AVP_UNSUPPORTED.  If the ISP selection mechanism
   defined in PANA need not use AVP value was unrecognized the alternative ISP selection mechanism.

5.11.  Error Handling

   A
         PANA-Error-Request message MAY result code MUST be sent by
         PANA_INVALID_AVP_DATA.  In either case the PaC or the PAA
   when a badly formed PANA PANA-Error-Request
         message is received or in case of other
   errors.  The receiver of this request MUST respond with a PANA-Error-
   Answer message.

   An adversary might craft erroneous PANA messages to launch carry a Denial
   of Service attack.  Unless Failed-AVP AVP containing the PaC or offending
         mandatory AVP.  AVPs with the PAA performs 'M' bit cleared are informational
         only and a rate-
   limitation of the generated PANA-Error-Request messages it may be
   overburdened by responding to bogus messages.  Note receiver that receives a PANA-
   Error-Answer message with such an AVP
         that is sent in response to a PANA-Error-Request
   message does not require either the PaC recognized, or the PAA to create a state.

   If an error message whose value is sent unprotected (i.e., without using an AUTH
   AVP) then the error message MUST be processed such that the receiver
   does not change its state.

6.  Header Format

   This section defines message formats for PANA protocol.

6.1.  IP and UDP Headers

   Any PANA message is unicast between the PaC and recognized, MAY
         simply ignore the PAA.  The source AVP.

      r(eserved)

         These flag bits are reserved for future use, and destination addresses SHOULD MUST be set to the addresses on the
   interfaces from which the message will be sent
         zero, and received,
   respectively.

   When ignored by the PANA message receiver.

   AVP Length

      The AVP Length field is sent in response to a request, the UDP
   source two octets, and destination ports of indicates the response message MUST be copied
   from number of
      octets in this AVP including the destination AVP Code, AVP Length, AVP Flags,
      and source ports of the request message,
   respectively.

   The source port of an unsolicited PANA message AVP data.

   Reserved

      This two-octet field is reserved for future use, and MUST be set
      to a value
   chosen zero, and ignored by the sender. receiver.

   Vendor-Id

      The destination port MUST be set to the peer's
   port number Vendor-Id field is present if it has already been discovered via earlier PANA
   exchanges, set to the assigned PANA port (To Be Assigned by IANA)
   otherwise.

6.2.  PANA Header

   A summary of the PANA header format 'V' bit is shown below. set in the AVP
      Flags field.  The fields are
   transmitted optional four-octet Vendor-Id field contains the
      IANA assigned "SMI Network Management Private Enterprise Codes"
      [ianaweb] value, encoded in network byte order.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |   Reserved    |        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Flags              |         Message Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  AVPs ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Version

      This Version field MUST be set to 1  Any vendor
      wishing to indicate implement a vendor-specific PANA Version 1.

   Reserved
      This 8-bit field is reserved for future use, and AVP MUST be set to
      zero, and ignored by the receiver.

   Message Length use their own
      Vendor-Id along with their privately managed AVP address space,
      guaranteeing that they will not collide with any other vendor's
      vendor-specific AVP(s), nor with future IETF applications.

   Data

      The Message Length Data field is two zero or more octets and indicates contains information
      specific to the Attribute.  The format and length of the PANA message including Data
      field is determined by the header AVP Code and AVP Length fields.

   Flags

      The

   Unless otherwise noted, AVPs defined in this document will have the
   following default AVP Flags field is two octets. settings: The following bits are assigned:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R L r r r r r r r r r r r r r r|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      R(equest)

         If set, the 'M' bit MUST be set.
   The 'V' bit MUST NOT be set.

7.  PANA Messages

   Each Request/Answer message pair is assigned a request.  If cleared, Sequence Number, and
   the message sub-type (i.e., request or answer) is
         an answer.

      L(stateLess handshake)

         When identified via the L-flag is set 'R' bit
   in a PANA-Start-Request message it
         indicates that the PAA is performing stateless handshake.
         Cookie AVP MUST be included in both the PANA-Start-Request and Message Flags field of the PANA-Start-Answer messages when performing stateless
         handshake.

      r(eserved)

         These flag bits are reserved for future use, and PANA message header.

   Every PANA message MUST be set to
         zero, and ignored by the receiver.

   Message Type

      The contain a message ID in its header's Message
   Type field is two octets, and field, which is used in order to
      communicate the message type with determine the message.  The 16-bit address
      space action that is managed by IANA [ianaweb].  PANA uses its own address
      space for this field.

   Sequence Number
      The Sequence Number field contains a 32 bit value.

   AVPs

      AVPs are a method of encapsulating information relevant to the
      PANA message.  See section Section 6.3 for more information on
      AVPs.

6.3.  AVP Header

   Each AVP of type OctetString MUST be padded to align on a 32-bit
   boundary, while other AVP types align naturally.  A number of zero-
   valued bytes are added to the end of the AVP Data field till taken
   for a word
   boundary is reached.  The length of the padding is not reflected in
   the AVP Length field [RFC3588].

   The fields in the AVP header are sent particular message.  Figure 8 lists all PANA messages defined
   in network byte order.  The
   format of the header is:

    0 this document:

   Message-Name              Abbrev. ID PaC<->PAA  Ref.
   ----------------------------------------------------------
   PANA-Client-Initiation     PCI    1  -------->  7.1
   PANA-Start-Request         PSR    2                   3
    0 1  <--------  7.2
   PANA-Start-Answer          PSA    2  -------->  7.3
   PANA-Auth-Request          PAR    3 4 5 6 7 8 9 0 1 2  <------->  7.4
   PANA-Auth-Answer           PAN    3  <------->  7.5
   PANA-Reauth-Request        PRR    4 5 6 7 8 9 0 1 2 3  -------->  7.6
   PANA-Reauth-Answer         PRA    4  <--------  7.7
   PANA-Bind-Request          PBR    5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AVP Code            |           AVP Flags           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Vendor-Id (opt)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+-+-+-+-+

   AVP Code

      The AVP Code, combined with the Vendor-Id field, identifies the
      attribute uniquely.  AVP numbers are allocated by IANA [ianaweb].
      PANA uses its own address space for this field although some of
      the AVP formats are borrowed from Diameter protocol [RFC3588].

   AVP Flags

      The AVP Flags field is two octets.  The following bits are
      assigned:

    0                   1
    0 1 2 3 4  <--------  7.8
   PANA-Bind-Answer           PBA    5  -------->  7.9
   PANA-Ping-Request          PPR    6  <------->  7.10
   PANA-Ping-Answer           PPA    6  <------->  7.11
   PANA-Termination-Request   PTR    7  <------->  7.12
   PANA-Termination-Answer    PTA    7  <------->  7.13
   PANA-Error-Request         PER    8  <------->  7.14
   PANA-Error-Answer          PEA    8  <------->  7.15
   PANA-Update-Request        PUR    9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V M r r r r r r r r r r r r r r|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      M(andatory)

         The 'M' Bit, known as the Mandatory bit, indicates whether
         support  <------->  7.16
   PANA-Update-Answer         PUA    9  <------->  7.17
   -----------------------------------------------------------

                     Figure 8: Table of the AVP is required.

         If an AVP with the 'M' bit set is received by the PaC or PAA
         and either the AVP or its value is unrecognized, the PANA Messages

   Every PANA message defined MUST be rejected and the receiver MUST send include a PANA-Error-
         Request message.  If the AVP was unrecognized corresponding ABNF
   [RFC2234] specification, which is used to define the PANA-Error-
         Request message result code AVPs that MUST
   or MAY be PANA_AVP_UNSUPPORTED.  If
         the AVP value was unrecognized present.  The following format is used in the PANA-Error-Request message
         result code MUST be PANA_INVALID_AVP_DATA.  In either case definition:

   message-def      = Message-Name "::=" PANA-message

   message-name     = PANA-name

   PANA-name        = ALPHA *(ALPHA / DIGIT / "-")

   PANA-message     = header  [ *fixed] [ *required] [ *optional]
                      [ *fixed]

   header           = "< PANA-Header: " Message-Type
                      [r-bit] ">"

   Message-Type     = 1*DIGIT
                      ; The Message Type assigned to the
         PANA-Error-Request message MUST carry a Failed-AVP AVP
         containing the offending mandatory AVP.

         AVPs with

   r-bit            = ", REQ"
                      ; If present, the 'M' 'R' bit cleared are informational only and a
         receiver in the Message
                      ; Flags is set, indicating that receives a the message with such an AVP that is not
         recognized, or whose value
                      ; is not recognized, MAY simply ignore a request, as opposed to an answer.

   fixed            = [qual] "<" avp-spec ">"
                      ; Defines the fixed position of an AVP.

      V(endor)

   required         = [qual] "{" avp-spec "}"
                      ; The 'V' bit, known as the Vendor-Specific bit, indicates
         whether the optional Vendor-Id field is present in the AVP
         header.  When set the AVP Code belongs to the specific vendor
         code address space.

      r(eserved)

         These flag bits are reserved for future use, and MUST be set to
         zero, present and ignored by the receiver.

      Unless otherwise noted, AVPs defined can appear
                      ; anywhere in this document will have the following default AVP Flags field settings: The 'M' bit MUST
      be set.  The 'V' bit MUST NOT be set.

   AVP Length message.

   optional         = [qual] "[" avp-name "]"
                      ; The avp-name in the 'optional' rule cannot
                      ; evaluate to any AVP Length field Name which is two octets, and indicates the number of
      octets included
                      ; in this a fixed or required rule.  The AVP including can
                      ; appear anywhere in the message.

   qual             = [min] "*" [max]
                      ; See ABNF conventions, RFC 2234 Section 6.6.
                      ; The absence of any qualifiers depends on whether
                      ; it precedes a fixed, required, or optional
                      ; rule.  If a fixed or required rule has no
                      ; qualifier, then exactly one such AVP Code, AVP Length, MUST
                      ; be present.  If an optional rule has no
                      ; qualifier, then 0 or 1 such AVP Flags, may be
                      ; present.
                      ;
                      ; NOTE:  "[" and "]" have a different meaning
                      ; than in ABNF (see the AVP data.

   Reserved

      This two-octet field is reserved for future use, and MUST optional rule, above).
                      ; These braces cannot be set used to zero, and ignored by express
                      ; optional fixed rules (such as an optional
                      ; AUTH at the receiver.

   Vendor-Id end).  To do this, the convention
                      ; is '0*1fixed'.

   min              = 1*DIGIT
                      ; The Vendor-Id field minimum number of times the element may
                      ; be present.  The default value is present if zero.

   max              = 1*DIGIT
                      ; The maximum number of times the 'V' bit element may
                      ; be present.  The default value is set in infinity.  A
                      ; value of zero implies the AVP
      Flags field. MUST NOT be
                      ; present.

   avp-spec         = PANA-name
                      ; The optional four-octet Vendor-Id field contains the
      IANA assigned "SMI Network Management Private Enterprise Codes"
      [ianaweb] value, encoded in network byte order.  Any vendor
      wishing avp-spec has to implement a vendor-specific PANA be an AVP MUST use their own
      Vendor-Id along with their privately managed Name, defined
                      ; in the base or extended PANA protocol
                      ; specifications.

   avp-name         = avp-spec / "AVP"
                      ; The string "AVP" stands for *any* arbitrary
                      ; AVP address space,
      guaranteeing that they will Name, which does not collide with any other vendor's
      vendor-specific AVP(s), nor conflict with future IETF applications.

   Data

      The Data field is zero the
                      ; required or more octets and contains information
      specific to fixed position AVPs defined in
                      ; the Attribute. message definition.

   Example-Request ::= < "PANA-Header: 9999999, REQ >
                       { Result-Code }
                    *  [ AVP ]
                   0*1 < AUTH >

7.1.  PANA-Client-Initiation (PCI)

   The format and length of the Data
      field PANA-Client-Initiation (PCI) message is determined by the AVP Code used for PaC-initiated
   handshake.  The Sequence Number and Session Identifier fields in this
   message MUST be set to zero (0).

   PANA-Client-Initiation ::= < PANA-Header: 1 >
                    *  [ AVP Length fields.

7.  PANA Messages

   Each Request/Answer ]

7.2.  PANA-Start-Request (PSR)

   The PANA-Start-Request (PSR) message pair is assigned a Sequence Number, and sent by the sub-type (i.e., request or answer) is identified via PAA to the 'R' bit
   in PaC to
   start PANA authentication.  The PAA sets the Message Flags Sequence Number field of to
   an initial random value and sets the PANA header.

   Every PANA message MUST contain Session Identifier field to a
   newly assigned value.

   PANA-Start-Request ::= < PANA-Header: 2, REQ >
                       [ EAP-Payload ]
                       [ Algorithm ]
                    *  [ AVP ]

7.3.  PANA-Start-Answer (PSA)

   The PANA-Start-Answer (PSA) message ID in its header's Message
   Type field, which is used sent by the PaC to determine the action that is PAA in
   response to be taken
   for a particular PANA-Start-Request message.  Figure 8 lists all  This message completes the
   handshake to start PANA messages defined
   in this document:

   Message-Name              Abbrev. ID PaC<->PAA  Ref.
   ----------------------------------------------------------
   PANA-Client-Initiation     PCI    1  -------->  7.1
   PANA-Start-Request         PSR    2  <--------  7.2 authentication.

   PANA-Start-Answer          PSA ::= < PANA-Header: 2  -------->  7.3 >
                       [ EAP-Payload ]
                    *  [ AVP ]

7.4.  PANA-Auth-Request          PAR    3  <------->  7.4
   PANA-Auth-Answer           PAN    3  <------->  7.5
   PANA-Reauth-Request        PRAR   4  -------->  7.6
   PANA-Reauth-Answer         PRAA   4  <--------  7.7
   PANA-Bind-Request          PBR    5  <--------  7.8
   PANA-Bind-Answer           PBA    5  -------->  7.9
   PANA-Ping-Request          PPR    6  <------->  7.10
   PANA-Ping-Answer           PPA    6  <------->  7.11
   PANA-Termination-Request   PTR    7  <------->  7.12
   PANA-Termination-Answer    PTA    7  <------->  7.13
   PANA-Error-Request         PER    8  <------->  7.14
   PANA-Error-Answer          PEA    8  <------->  7.15
   PANA-Update-Request        PUR    9  <------->  7.16
   PANA-Update-Answer         PUA    9  <------->  7.17
   -----------------------------------------------------------

   Figure 8: Table of PANA Messages

   Every PANA (PAR)

   The PANA-Auth-Request (PAR) message defined MUST include a corresponding ABNF
   [RFC2234] specification, which is used to define either sent by the AVPs that MUST PAA or MAY be present.  The following format is used in the definition:

   message-def      = Message-Name "::=" PANA-message

   message-name     = PANA-name

   PANA-name        = ALPHA *(ALPHA / DIGIT / "-")

   PANA-message     = header  [ *fixed] [ *required]
   PaC.  Its main task is to carry an EAP-Payload AVP.

   PANA-Auth-Request ::= < PANA-Header: 3, REQ >
                       < EAP-Payload >
                       [ *optional] Nonce ]
                    *  [ *fixed]

   header           = "< PANA-Header: " Message-Type
                      [r-bit] [s-bit] [n-bit] ">"

   Message-Type     = 1*DIGIT
                      ; AVP ]
                   0*1 < AUTH >

7.5.  PANA-Auth-Answer (PAN)

   The Message Type assigned to the PANA-Auth-Answer (PAN) message

   r-bit            = ", REQ"
                      ; If present, the 'R' bit in the Message
                      ; Flags is set, indicating that sent by either the message
                      ; is a request, as opposed PaC or the
   PAA in response to a PANA-Auth-Request message.  It MAY carry an answer.

   l-bit            = ", SLS"
                      ; If present,
   EAP-Payload AVP.

   PANA-Auth-Answer ::= < PANA-Header: 3 >
                       [ Nonce ]
                       [ EAP-Payload ]
                    *  [ AVP ]
                   0*1 < AUTH >

7.6.  PANA-Reauth-Request (PRR)

   The PANA-Reauth-Request (PRR) message is sent by the 'L' bit in PaC to the Message
                      ; Flags is set, indicating PAA
   to re-initiate EAP authentication.

   PANA-Reauth-Request ::= < PANA-Header: 4, REQ >
                    *  [ AVP ]
                   0*1 < AUTH >

7.7.  PANA-Reauth-Answer (PRA)

   The PANA-Reauth-Answer (PRA) message is performing
                      ; stateless handshake.

   fixed            = [qual] "<" avp-spec ">"
                      ; Defines sent by the fixed position of an AVP.

   required         = [qual] "{" avp-spec "}"
                      ; The AVP MUST be present and can appear
                      ; anywhere in PAA to the PaC in
   response to a PANA-Reauth-Request message.

   optional         = [qual] "[" avp-name "]"
                      ;

   PANA-Reauth-Answer ::= < PANA-Header: 4 >
                    *  [ AVP ]
                   0*1 < AUTH >

7.8.  PANA-Bind-Request (PBR)

   The avp-name in PANA-Bind-Request (PBR) message is sent by the 'optional' rule cannot
                      ; evaluate PAA to any the PaC to
   deliver the result of PANA authentication.

   PANA-Bind-Request ::= < PANA-Header: 5, REQ >
                       { Result-Code }
                       [ EAP-Payload ]
                       [ Session-Lifetime ]
                       [ Key-Id ]
                       [ Algorithm ]
                    *  [ AVP Name which ]
                   0*1 < AUTH >

7.9.  PANA-Bind-Answer (PBA)

   The PANA-Bind-Answer (PBA) message is included
                      ; sent by the PaC to the PAA in
   response to a fixed or required rule.  The AVP can
                      ; appear anywhere in the PANA-Bind-Request message.

   qual             = [min] "*" [max]
                      ; See ABNF conventions, RFC 2234 Section 6.6.
                      ; The absence of any qualifiers depends on whether
                      ; it precedes a fixed, required, or optional
                      ; rule.  If a fixed or required rule has no
                      ; qualifier, then exactly one such AVP MUST
                      ; be present.  If an optional rule has no
                      ; qualifier, then 0 or 1 such

   PANA-Bind-Answer ::= < PANA-Header: 5 >
                       [ Key-Id ]
                    *  [ AVP may be
                      ; present.
                      ;
                      ; NOTE:  "[" and "]" have a different meaning
                      ; than in ABNF (see the optional rule, above).
                      ; These braces cannot be used to express
                      ; optional fixed rules (such as an optional
                      ; ]
                   0*1 < AUTH at the end).  To do this, the convention
                      ; is '0*1fixed'.

   min              = 1*DIGIT
                      ; The minimum number of times the element may
                      ; be present.  The default value is zero.

   max              = 1*DIGIT
                      ; The maximum number of times the element may
                      ; be present. >

7.10.  PANA-Ping-Request (PPR)

   The default value PANA-Ping-Request (PPR) message is infinity.  A
                      ; value of zero implies the AVP MUST NOT be
                      ; present.

   avp-spec         = PANA-name
                      ; The avp-spec has to be an AVP Name, defined
                      ; in the base or extended PANA protocol
                      ; specifications.

   avp-name         = avp-spec / "AVP"
                      ; The string "AVP" stands for *any* arbitrary
                      ; AVP Name, which does not conflict with either sent by the
                      ; required PaC or fixed position AVPs defined in
                      ; the message definition.

   Example-Request
   PAA for performing liveness test.

   PANA-Ping-Request ::= < "PANA-Header: 9999999, PANA-Header: 6, REQ >
                       < Session-Id >
                       { Result-Code }
                    *  [ AVP ]
                   0*1 < AUTH >

7.1.  PANA-Client-Initiation (PCI)

7.11.  PANA-Ping-Answer (PPA)

   The PANA-Client-Initiation (PCI) PANA-Ping-Answer (PPA) message is used for PaC-initiated
   handshake.  The sequence number sent in this message is always set response to zero
   (0).

   PANA-Client-Initiation a
   PANA-Ping-Request.

   PANA-Ping-Answer ::= < PANA-Header: 1 6 >
                       [ Notification ]
                    *  [ AVP ]

7.2.  PANA-Start-Request (PSR)
                   0*1 < AUTH >

7.12.  PANA-Termination-Request (PTR)

   The PANA-Start-Request (PSR) PANA-Termination-Request (PTR) message is sent either by the PAA to the PaC to
   start PANA authentication.  The PAA sets
   or the sequence number PAA to an
   initial random value.

   PANA-Start-Request terminate a PANA session.

   PANA-Termination-Request ::= < PANA-Header: 2, 7, REQ [,SLS] >
                       [ Nonce ]
                       [ Cookie ]
                       [ EAP-Payload ]
                       [ NAP-Information ]
                    *  [ ISP-Information ]
                       [ Protection-Capability]
                       [ Algorithm ]
                       [ PPAC ]
                       [ Notification ]
                       < Termination-Cause >
                    *  [ AVP ]

7.3.  PANA-Start-Answer (PSA)
                   0*1 < AUTH >

7.13.  PANA-Termination-Answer (PTA)

   The PANA-Start-Answer (PSA) PANA-Termination-Answer (PTA) message is sent either by the PaC to
   or the PAA in response to a PANA-Start-Request message.  This message completes the
   handshake to start PANA authentication.

   PANA-Start-Answer PANA-Termination-Request.

   PANA-Termination-Answer ::= < PANA-Header: 2 7 >
                       [ Nonce ]
                       [ Cookie ]
                       [ EAP-Payload ]
                       [ ISP-Information ]
                       [ Notification ]
                    *  [ AVP ]

7.4.  PANA-Auth-Request (PAR)
                   0*1 < AUTH >

7.14.  PANA-Error-Request (PER)

   The PANA-Auth-Request (PAR) PANA-Error-Request (PER) message is either sent either by the PAA PaC or the
   PaC.  Its main task is
   PAA to carry report an EAP-Payload AVP.

   PANA-Auth-Request error with the last received PANA message.  This
   message MUST contain one Failed-Message-Header AVP which carries the
   content of the PANA message header of the erroneous message.

   PANA-Error-Request ::= < PANA-Header: 3, 8, REQ >
                        < Session-Id >
                       < EAP-Payload Result-Code >
                        { Failed-Message-Header }
                     *  [ Nonce ]
                       [ Notification Failed-AVP ]
                     *  [ AVP ]
                    0*1 < AUTH >

7.5.  PANA-Auth-Answer (PAN)

7.15.  PANA-Error-Answer (PEA)

   The PANA-Auth-Answer (PAN) PANA-Error-Answer (PEA) message is sent by either the PaC or the
   PAA in response to a PANA-Auth-Request message.  It MAY carry an EAP-
   Payload AVP.

   PANA-Auth-Answer
   PANA-Error-Request.

   PANA-Error-Answer ::= < PANA-Header: 3 >
                       < Session-Id 8 >
                       [ Nonce ]
                       [ EAP-Payload ]
                       [ Notification ]
                     *  [ AVP ]
                    0*1 < AUTH >

7.6.  PANA-Reauth-Request (PRAR)

7.16.  PANA-Update-Request (PUR)

   The PANA-Reauth-Request (PRAR) PANA-Update-Request (PUR) message is sent either by the PaC to or
   the PAA to re-initiate EAP authentication.

   PANA-Reauth-Request deliver attribute updates.  In the scope of this
   specification only the IP address the PaC can be updated via this
   message.

   PANA-Update-Request ::= < PANA-Header: 4, 9, REQ >
                       < Session-Id >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < AUTH >

7.7.  PANA-Reauth-Answer (PRAA)

7.17.  PANA-Update-Answer (PUA)

   The PANA-Reauth-Answer (PRAA) PANA-Update-Answer (PUA) message is sent by the PAA (PaC) to the
   PaC (PAA) in response to a PANA-Reauth-Request message.

   PANA-Reauth-Answer ::= < PANA-Header: 4 >
                       < Session-Id >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < AUTH >

7.8.  PANA-Bind-Request (PBR)

   The PANA-Bind-Request (PBR) message is sent by the PAA to PANA-Update-Request from the PaC to
   deliver the result of PANA authentication.

   PANA-Bind-Request (PAA).

   PANA-Update-Answer ::= < PANA-Header: 5, REQ >
                       < Session-Id 9 >
                       { Result-Code }
                       [ PPAC ]
                       [ EAP-Payload ]
                       [ Session-Lifetime ]
                       [ Protection-Capability ]
                       [ Key-Id ]
                       [ Algorithm ]
                    *  [ Device-Id ]
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < AUTH >

7.9.  PANA-Bind-Answer (PBA)

8.  AVPs in PANA

   This document uses AVP Data Format such as 'OctetString' and
   'Unsigned32' as defined in Section 4.2 of [RFC3588].  The PANA-Bind-Answer (PBA) message is sent by definitions
   of these data formats are not repeated in this document.

   The following tables lists the PaC to AVPs used in this document, and
   specifies in which PANA messages they MAY, or MAY NOT be present.

   The table uses the PAA following symbols:

   0     The AVP MUST NOT be present in
   response to a PANA-Bind-Request the message.

   PANA-Bind-Answer ::= < PANA-Header: 5 >
                       < Session-Id >
                       [ PPAC ]
                       [ Device-Id ]
                       [ Key-Id ]
                       [ Notification ]
                    *  [

   0+    Zero or more instances of the AVP ]
                   0*1 < AUTH >

7.10.  PANA-Ping-Request (PPR)

   The PANA-Ping-Request (PPR) message is either sent by MAY be present in the PaC
         message.

   0-1   Zero or one instance of the
   PAA for performing liveness test.

   PANA-Ping-Request ::= < PANA-Header: 6, REQ >
                       < Session-Id >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < AUTH >

7.11.  PANA-Ping-Answer (PPA)

   The PANA-Ping-Answer (PPA) message is sent MAY be present in response to a PANA-
   Ping-Request.

   PANA-Ping-Answer ::= < PANA-Header: 6 >
                       < Session-Id >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < AUTH >

7.12.  PANA-Termination-Request (PTR)

   The PANA-Termination-Request (PTR) message is sent either by the PaC
   or the PAA to terminate a PANA session.

   PANA-Termination-Request ::= < PANA-Header: 7, REQ >
                       < Session-Id >
                       < Termination-Cause >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < AUTH >

7.13.  PANA-Termination-Answer (PTA)

   The PANA-Termination-Answer (PTA) message is sent either by the PaC
   or the PAA in response to PANA-Termination-Request.

   PANA-Termination-Answer ::= < PANA-Header: 7 >
                       < Session-Id >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < AUTH >

7.14.  PANA-Error-Request (PER)

   The PANA-Error-Request (PER) message message.
         It is sent either by the PaC or the
   PAA to report considered an error with if there are more than one instance
         of the AVP.

   1     One instance of the last received PANA message.

   PANA-Error-Request ::= < PANA-Header: 8, REQ >
                        < Session-Id >
                        < Result-Code >
                     *  [ Failed-AVP ]
                        [ Notification ]
                     *  [ AVP ]
                    0*1 < AUTH >

7.15.  PANA-Error-Answer (PEA)

   The PANA-Error-Answer (PEA) message is sent MUST be present in response to a PANA-
   Error-Request.

   PANA-Error-Answer ::= < PANA-Header: 8 >
                        < Session-Id >
                        [ Notification ]
                     *  [ AVP ]
                    0*1 < AUTH >

7.16.  PANA-Update-Request (PUR)

   The PANA-Update-Request (PUR) message is sent either by the PaC or
   the PAA to deliver attribute updates and notifications.  In the scope
   of this specification only the IP address and device identifer of the
   PaC can be updated via this message.

   PANA-Update-Request ::= < PANA-Header: 9, REQ >
                       < Session-Id >
                       [ Device-Id ]
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < AUTH >

7.17.  PANA-Update-Answer (PUA)

   The PANA-Update-Answer (PUA) message is sent by the PAA (PaC) to the
   PaC (PAA) in response to a PANA-Update-Request from the PaC (PAA).

   PANA-Update-Answer ::= < PANA-Header: 9 >
                       < Session-Id >
                    *  [ Device-Id ]
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < AUTH >

8.  AVPs in PANA

   PANA defines several AVPs that are specific to the protocol.  A
   number of others AVPs are reused.  These are specified in other
   documents such as [RFC3588].

   The following tables lists the AVPs used in this document, and
   specifies in which PANA messages they MAY, or MAY NOT be present.

   The table uses the following symbols:

   0     The AVP MUST NOT be present in the message.

   0+    Zero or more instances of the AVP MAY be present in the
         message.

   0-1   Zero or one instance of the AVP MAY be present in the message.
         It is considered an error if there are more than one instance
         of the AVP.

   1     One instance of the AVP MUST be present in the message.

   1+    At least one instance message.

   1+    At least one instance of the AVP MUST be present in the
         message.

                         +---------------------------------------------+

                         +-------------------------------------------+
                         |               Message Type                |
                         +---+---+---+---+---+----+----+---+---+---+---+
                         +---+---+---+---+---+---+---+---+---+---+---+
   Attribute Name        |PCI|PSR|PSA|PAR|PAN|PRAR|PRAA|PBR|PBA|PPR|PPA|
   ----------------------+---+---+---+---+---+----+----+---+---+---+---+        |PCI|PSR|PSA|PAR|PAN|PRR|PRA|PBR|PBA|PPR|PPA|
   ----------------------+---+---+---+---+---+---+---+---+---+---+---+
   Algorithm             | 0 |0-1| 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 |
   AUTH                  | 0 | 0 | 0 |0-1|0-1|0-1 |0-1 |0-1|0-1|0-1|0-1|
   Cookie |0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|
   EAP-Payload           | 0 |0-1|0-1| 1 |0-1| 0 | 0 | |0-1| 0 | 0 | 0 | 0
   Failed-AVP            | 0 | 0 |
   Device-Id             | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0+|0-1| 0 | 0 |
   EAP-Payload
   Failed-Message-Header | 0 |0-1|0-1| 1 |0-1| 0 | 0  |0-1| 0 | 0 | 0 |
   Failed-AVP            | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
   Key-Id                | 0 | 0 | 0 |
   ISP-Information 0 | 0 | 0+|0-1| 0 | 0 |0-1|0-1| 0 | 0 |
   Nonce                 | 0 | 0 | 0 |0-1|0-1| 0 | 0 | 0 |
   Key-Id 0 | 0 | 0 |
   Result-Code           | 0 | 0 | 0 | 0 | 0  |0-1|0-1| | 0 | 0 |
   NAP-Information 1 | 0 |0-1| 0 | 0 | 0 | 0
   Session-Lifetime      | 0 | 0 | 0 | 0 | 0 |
   Nonce 0 | 0 |0-1|0-1|0-1|0-1| |0-1| 0 | 0 | 0 | 0
   Termination-Cause     | 0 | 0 |
   Notification          |0-1|0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1|0-1|0-1|
   PPAC 0 | 0 |0-1| | 0 | 0 | 0 | 0 | 0  |0-1|0-1| | 0 | 0 |
   Protection-Capability | 0 |0-1| 0 | 0 | 0 | 0  | 0  |0-1| 0 | 0 | 0 |
   Result-Code           | 0 | 0 | 0 | 0 | 0 | 0  | 0  | 1 | 0 | 0 | 0 |
   Session-Id            | 0 | 0 | 0 | 1 | 1 | 1  | 1  | 1 | 1 | 1 | 1 |
   Session-Lifetime      | 0 | 0 | 0 | 0 | 0 | 0  | 0  |0-1| 0 | 0 | 0 |
   Termination-Cause     | 0 | 0 | 0 | 0 | 0 | 0  | 0  | 0 | 0 | 0 | 0 |
   ----------------------+---+---+---+---+---+----+----+---+---+---+---+
   ----------------------+---+---+---+---+---+---+---+---+---+---+---+

                   Figure 9: AVP Occurrence Table (1/2)
                         +-----------------------+
                         |     Message Type      |
                         +---+---+---+---+---+---+
   Attribute Name        |PTR|PTA|PER|PEA|PUR|PUA|
   ----------------------+---+---+---+---+---+---+
   Algorithm             | 0 | 0 | 0 | 0 | 0 | 0 |
   AUTH                  |0-1|0-1|0-1|0-1|0-1|0-1|
   Cookie                | 0 | 0 | 0 | 0 | 0 | 0 |
   Device-Id             | 0 | 0 | 0 | 0 | 0 | 0 |
   EAP-Payload           | 0 | 0 | 0 | 0 | 0 | 0 |
   Failed-AVP            | 0 | 0 | 0+| 0 | 0 | 0 |
   ISP-Information
   Failed-Message-Header | 0 | 0 | 0 1 | 0 | 0 | 0 |
   Key-Id                | 0 | 0 | 0 | 0 | 0 | 0 |
   NAP-Information       | 0 | 0 | 0 | 0 | 0 | 0 |
   Nonce                 | 0 | 0 | 0 | 0 | 0 | 0 |
   Notification          |0-1|0-1|0-1|0-1|0-1|0-1|
   PPAC                  | 0 | 0 | 0 | 0 | 0 | 0 |
   Protection-Capability | 0 | 0 | 0 | 0 | 0 | 0 |
   Result-Code           | 0 | 0 | 1 | 0 | 0 | 0 |
   Session-Id            | 1 | 1 | 1 | 1 | 1 | 1 |
   Session-Lifetime      | 0 | 0 | 0 | 0 | 0 | 0 |
   Termination-Cause     | 1 | 0 | 0 | 0 | 0 | 0 |
   ----------------------+---+---+---+---+---+---+

                   Figure 10: AVP Occurrence Table (2/2)

8.1.  Algorithm AVP

   The Algorithm AVP (AVP Code 1) is used for conveying the pseudo-
   random
   pseudo-random function to derive PANA_AUTH_KEY and PaC-EP-Master-Key as well as the
   integrity algorithm to compute an AUTH AVP.  The AVP data is of type
   Unsigned32.

   The first 16-bit of the AVP data contains an IKEv2 Transform ID of
   Transform Type 2 [RFC4306] corresponding to the key derivation
   function.

   The last 16-bit of the AVP data contains an IKEv2 Transform ID of
   Transform Type 3 [RFC4306] for the integrity algorithm.

   All PANA implementations MUST support PRF_HMAC_SHA1 (2) [RFC2104] for
   the key derivation algorithm and AUTH_HMAC_SHA1_160 (7) [ianaweb] [RFC4595]
   corresponding to the integrity algorithm.

8.2.  AUTH AVP

   The AUTH AVP (AVP Code 2) is used to integrity protect PANA messages.
   The AVP data payload contains the Message Authentication Code encoded
   in network byte order.  The AVP length varies depending on the
   integrity algorithm specified in an Algorithm AVP.

8.3.  Cookie  EAP-Payload AVP

   The Cookie EAP-Payload AVP (AVP Code 3) is used for carrying a random value
   generated by encapsulating the PAA according to [RFC4086]. actual
   EAP message that is being exchanged between the EAP peer and the EAP
   authenticator.  The AVP data is of type OctetString.

8.4.  Failed-AVP AVP

   The random value Failed-AVP AVP (AVP Code 4) provides debugging information in
   cases where a message is referred rejected or not fully processed due to as a cookie and used
   for making the handshake phase robust against blind resource
   consumption DoS attacks.  The exact algorithms and syntax used by the
   PAA to generate a cookie does not affect interoperability and not
   specified in this document.

8.4.  Device-Id AVP

   The Device-Id AVP (AVP Code 4) is used for carrying device
   identifiers of PaC and EP(s).  The AVP data is of Address type
   [RFC3588].  IPv4 and IPv6 addresses are encoded as specified in
   [RFC3588].  The content and format of data (including byte and bit
   ordering) for link-layer addresses is expected to be specified in
   specific documents that describe how IP operates over different link-
   layers.  For instance, [RFC2464].  Address families other than that
   are defined for link-layer or IP addresses MUST NOT be used for this
   AVP.

8.5.  EAP-Payload AVP

   The EAP-Payload AVP (AVP Code 5) is used for encapsulating the actual
   EAP message that is being exchanged between the EAP peer and the EAP
   authenticator.  The AVP data is of type OctetString.

8.6.  Failed-AVP AVP

   The Failed-AVP AVP (AVP Code 6) provides debugging information in
   cases where a request is rejected or not fully processed due to
   erroneous information in
   erroneous information in a specific AVP.  The AVP data is of type
   Grouped.  The format of the Failed-AVP AVP is using the ABNF grammar
   defined in [RFC3588]. [RFC3588] for Grouped AVP is as follows.

           <Failed-AVP> ::= < AVP Header: 4 >
                         1* {AVP}

   In case of a failed grouped AVP, the Failed-AVP contains the whole
   grouped AVP.  In case of a failed AVP inside a grouped AVP, the
   Failed-AVP contains the single offending AVP.

8.7.  ISP-Information

8.5.  Failed-Message-Header AVP

   The ISP-Information Failed-Message-Header AVP (AVP Code 7) contains zero 5) provides debugging
   information in cases where a message is rejected or one Provider-
   Identifier AVP which carries the identifier of the ISP and one
   Provider-Name AVP which carries the name of not fully
   processed due to erroneous information in the ISP. message.  The AVP data
   is of type Grouped, and it has the following ABNF grammar:

   ISP-Information ::= < AVP Header: 7 >
                    0*1 { Provider-Identifier }
                        { Provider-Name }
                     *  [ OctetString.  The AVP ]

8.8. data contains the 16-octet header of
   the message that caused the error.

8.6.  Key-Id AVP

   The Key-Id AVP (AVP Code 8) 6) is of type Integer32, and contains an MSK
   identifier.  The MSK identifier is assigned by PAA and MUST be unique
   within the PANA session.

8.9.  NAP-Information AVP

   The NAP-Information AVP (AVP Code 9) contains zero or one Provider-
   Identifier AVP which carries the identifier of the NAP and one
   Provider-Name AVP which carries the name of the NAP.  The AVP data is
   of type Grouped, and it has the following ABNF grammar:

   NAP-Information ::= < AVP Header: 9 >
                    0*1 { Provider-Identifier }
                        { Provider-Name }
                     *  [ AVP ]

8.10.

8.7.  Nonce AVP

   The Nonce AVP (AVP Code 10) 7) carries a randomly chosen value that is
   used in cryptographic key computations.  The recommendations in
   [RFC4086] apply with regard to generation of random values.  The AVP
   data is of type OctetString and it contains a randomly generated
   value in opaque format.  The data length MUST be between 8 and 256
   octets inclusive.

   The length of the nonces are determined based on the available
   pseudo-random functions (PRFs) and the degree of trust placed into
   the two PaC and the PAA to compute random values.  The length of the
   random value for the nonce is determined whether

   1.  The PaC and the PAA each are likely to be able to compute a
       random nonce (according to [RFC4086]).  The length of the nonce
       has to be 1/2 the length of the PRF key (e.g., 10 octets in the
       case of HMAC-SHA1).

   2.  The PaC and the PAA each are not trusted with regard to the
       computation a random nonce (according to [RFC4086]).  The length
       of the nonce has to have the full length of the PRF key (e.g., 20
       octets in the case of HMAC-SHA1).

   Furthermore, the strongest available PRF available for PANA has to be
   considered in this computation.  Currently, only a single PRF (namely
   HMAC-SHA1) is available and therefore the maximum output length is 20
   octets).  The recommended maximum length of the nonce value is
   therefore currently 20 octets.

8.11.  Notification

8.8.  Result-Code AVP

   The Notification Result-Code AVP (AVP Code 11) 8) is optionally used to convey a
   displayable message sent by either of type Unsigned32 and indicates
   whether an EAP authentication was completed successfully or whether
   an error occurred.  Result-Code AVP values are described in the
   subsequent sections.

8.8.1.  Authentication Results Codes

   These result code values inform the PaC or about the PAA.  It authentication and
   authorization result.  The authentication result and authorization
   result can be
   included in any message, whether it is a request or answer.  In case
   a notification needs to be sent different as described below, but there only one result is no outgoing PANA message
   returned to deliver this AVP, a PANA-Update-Request that only carries a
   Notification AVP SHOULD be generated.

   The 'M' bit in the AVP header of this AVP MUST NOT be set.

   Receipt PaC.  These codes are used with PANA-Bind-Request
   message.

   PANA_SUCCESS                               0

      Both authentication and authorization processes are successful.

   PANA_AUTHENTICATION_REJECTED               1

      Authentication has failed.  When this AVP does not change PANA state.

   AVP data error is of type OctetString and returned, it contains the following fields
   in the listed order:

   Language Tag Length

      This field contains the length of the Language Tag in octets.  The
      length of this field is
      assumed that authorization is automatically failed.

   PANA_AUTHORIZATION_REJECTED                2 octets.

   Language Tag

      This field contains the language tag defined in [I-D.ietf-ltru-
      registry] to indicate the language used for Displayable String.

      The length of this data authorization process has failed.  This error could occur when
      authorization is determined rejected by a AAA server or rejected locally by a
      PAA, even if the Language Tag Length
      field.

   Displayable String

      This field contains UTF-8 encoded ISO 10646 characters [RFC2279]
      using the language indicated authentication procedure has succeeded.

8.8.2.  Protocol Error Result Codes

   These codes are used with PANA-Error-Request messages.  Unless stated
   otherwise, they can be generated by both the Language Tag. PaC and the PAA.

   PANA_MESSAGE_UNSUPPORTED                1001

      Message type not recognized or supported.

   PANA_UNABLE_TO_DELIVER                  1002

      The length of PAA was unable to deliver the EAP payload to the
      authentication server.  Only the PAA can generate this data code.

   PANA_INVALID_HDR_BITS                   1003

      A message was received whose bits in the PANA message header were
      either set to an invalid combination, or to a value that is determined by
      inconsistent with the message type definition.

   PANA_INVALID_AVP_FLAGS                  1004

      A message was received that included an AVP Length field and whose flag bits are
      set to an unrecognized value, or that is inconsistent with the Language
      Tag Length field.  This data MUST NOT be null terminated.

8.12.  Post-PANA-Address-Configuration (PPAC) AVP
      AVP's definition.

   PANA_AVP_UNSUPPORTED                    1005

      The PPAC received message contained an AVP (AVP Code 12) that is used for conveying the available types
   of post-PANA IP address configuration mechanisms when sent by the
   PAA, not recognized or
      supported and was marked with the chosen Mandatory bit.  A PANA message
      with this error MUST contain one when sent by or more Failed-AVP AVP containing
      the PaC.  Each possible
   mechanisms is represented by a flag. AVPs that caused the failure.

   PANA_INVALID_AVP_DATA                   1006

      The message contained an AVP with an invalid value in its data is of type
   Unsigned32.

   The format of
      portion.  A PANA message indicating this error MUST include the
      offending AVPs within a Failed-AVP AVP.

   PANA_MISSING_AVP                        1007

      The message did not contain an AVP data that is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|F|S|A|T|I|                    Reserved                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PPAC Flags

      N (No configuration)

         The PaC does not have to (if sent by PAA) or will not (if sent
         by PaC) configure a new IP address after PANA.

      F (DHCPv4)

         The PaC can (if sent by PAA) or will (if sent by PaC) use
         DHCPv4 [RFC2131] to configure a new IPv4 address after PANA.

      S (DHCPv6)

         The PaC can (if sent required by PAA) or will (if the message
      type definition.  If this value is sent by PaC) use
         DHCPv6 [RFC3315] to configure a new IPv6 address after PANA.

      A (stateless autoconfiguration)

         The PaC can/will use stateless IPv6 address autoconfiguration
         [RFC2462] to configure a new IPv6 address after PANA.

      T (DHCPv4 with IPsec tunnel mode)

         The PaC can/will use [RFC3456] to configure in the Result-Code AVP, a new IPv4 address
         after PANA.

      I (IKEv2)

         The PaC can/will use [RFC4306] to configure (a) new IPv4 and/or
         IPv6 address(es) after PANA.

      Reserved

         These flag bits are reserved for future use, and MUST
      Failed-AVP AVP SHOULD be set to
         zero, and ignored by included in the receiver. message.  The PAA Failed-AVP
      AVP MUST set either the N-flag, or one or more contain an example of the other
   flags.  If the N-flag is set, the PaC MUST only set its N-flag in its
   response.  If missing AVP complete with the N-flag is not set by
      Vendor-Id if applicable.  The value field of the PAA, missing AVP
      should be of correct minimum length and contain zeroes.

   PANA_RESOURCES_EXCEEDED                 1008

      A message was received that means the PaC
   MUST configure POPA(s) using the method(s) indicated by the flags.
   If IPsec-based access control is not used, the F-flag, S-flag or
   A-flag MUST cannot be set by authorized because the PAA,
      client has already expended allowed resources.  An example of this
      error condition is a client that is restricted to one PANA session
      and the PaC MUST echo the same flag(s)
   in its response.  Refer attempts to [I-D.ietf-pana-framework] for establish a detailed
   discussion on when these methods second session.  Only the PAA can be used.

8.13.  Protection-Capability AVP
      generate this code.

   PANA_CONTRADICTING_AVPS                 1009

      The Protection-Capability AVP (AVP Code 13) indicates PAA has detected AVPs in the
   cryptographic data protection capability supported message that contradicted each
      other, and required by
   the EPs.  The AVP data is of type Unsigned32.  Below is a list of
   valid data values and associated protection capabilities:

      0          L2_PROTECTION
      1          IPSEC_PROTECTION

8.14.  Provider-Identifier not willing to provide service to the client.  One
      or more Failed-AVP AVPs MUST be present, containing the AVPs that
      contradicted each other.  Only the PAA can generate this code.

   PANA_AVP_NOT_ALLOWED                    1010

      A message was received with an AVP that MUST NOT be present.  The Provider-Identifier
      Failed-AVP AVP (AVP Code 14) is of type Unsigned32, MUST be included and
   contains contain a copy of the
      offending AVP.

   PANA_AVP_OCCURS_TOO_MANY_TIMES          1011

      A message was received that included an IANA assigned "SMI Network Management Private Enterprise
   Codes" [ianaweb] value, encoded in network byte order.

8.15.  Provider-Name AVP that appeared more
      often than permitted in the message definition.  The Provider-Name Failed-AVP
      AVP (AVP Code 15) is of type UTF8String, MUST be included and
   contains contain a copy of the UTF8-encoded name first instance of
      the provider.

8.16.  Result-Code AVP

   The Result-Code offending AVP (AVP Code 16) is that exceeded the maximum number of type Unsigned32 and indicates
   whether occurrences.

   PANA_UNSUPPORTED_VERSION                1012

      This error is returned when a message was received, whose version
      number is unsupported.

   PANA_UNABLE_TO_COMPLY                   1013

      This error is returned when a request is rejected for unspecified
      reasons.  For example, when an EAP authentication was completed successfully or whether fails at an error occurred.  Here are EAP
      pass-through authenticator without passing an EAP Failure message
      to the PAA, a Result-Code AVP values taken from
   [RFC3588] and adapted for PANA.

8.16.1.  Authentication Results Codes

   These result with this error code values inform the PaC about the authentication and
   authorization result.  The authentication result and authorization
   result can be different as described below, but only one result is
   returned to carried in
      the PaC.  These codes are used with PANA-Bind-Request PANA-Error-Request message.

   PANA_SUCCESS                            2001

      Both authentication and authorization processes are successful.

   PANA_AUTHENTICATION_REJECTED            4001

      Authentication has failed.  When

   PANA_INVALID_AVP_LENGTH 1014

      The message contained an AVP with an invalid length.  The
      PANA-Error-Request message indicating this error MUST include the
      offending AVPs within a Failed-AVP AVP.

   PANA_INVALID_MESSAGE_LENGTH             1015

      This error is returned, it returned when a message is
      assumed that authorization received with an invalid
      message length.

8.9.  Session-Lifetime AVP

   The Session-Lifetime AVP (AVP Code 9) contains the number of seconds
   remaining before the current session is automatically failed.

   PANA_AUTHORIZATION_REJECTED             5003 considered expired.  The authorization process has failed.  This error could occur when
      authorization AVP
   data is rejected by of type Unsigned32.

8.10.  Termination-Cause AVP

   The Termination-Cause AVP (AVP Code 10) is used for indicating the
   reason why a AAA server or rejected locally session is terminated by a
      PAA, even if the authentication procedure has succeeded.

8.16.2.  Protocol Error Result Codes

   These codes requester.  The AVP data is
   of type Enumerated.  The following Termination-Cause data values are
   used with PANA-Error-Request messages.  Unless stated
   otherwise, they can be generated by both the PaC and the PAA.

   PANA_MESSAGE_UNSUPPORTED                3001

      Message type PANA.

   LOGOUT                   1  (PaC -> PAA)

      The client initiated a disconnect

   ADMINISTRATIVE           4  (PAA -> PaC)

      The client was not recognized granted access, or supported.

   PANA_UNABLE_TO_DELIVER                  3002

      The PAA was unable to deliver the EAP payload disconnected, due to
      administrative reasons.

   SESSION_TIMEOUT          8  (PAA -> PaC)

      The session has timed out, and service has been terminated.

9.  Retransmission Timers

   The PANA protocol provides retransmissions for the
      authentication server.  Only
   PANA-Client-Initiation message and all request messages.

   PANA retransmission timers are based on the PAA can generate model used in DHCPv6
   [RFC3315].  Variables used here are also borrowed from this code.

   PANA_INVALID_HDR_BITS                   3008

      A
   specification.  PANA is a request response like protocol.  The
   message was received whose bits in exchange terminates when the PANA header were either
      set to an invalid combination, request sender successfully
   receives the appropriate answer, or to when a value that protected
   PANA-Error-Request message for the request is inconsistent
      with received, or when the
   message type definition.

   PANA_INVALID_AVP_FLAGS                   3009

      A message was received that included an AVP whose flag bits are
      set to an unrecognized value, or that exchange is inconsistent with considered to have failed according to the
      AVP's definition.

   PANA_AVP_UNSUPPORTED                    5001
   retransmission mechanism described below.

   The received message contained an AVP that retransmission behavior is not recognized or
      supported controlled and was marked with described by the Mandatory bit.  A PANA
   following variables:

         RT     Retransmission timeout

         IRT    Initial retransmission time

         MRC    Maximum retransmission count

         MRT    Maximum retransmission time

         MRD    Maximum retransmission duration

         RAND   Randomization factor

   With each message
      with this error MUST contain one transmission or more Failed-AVP AVP containing retransmission, the AVPs that caused sender sets RT
   according to the failure.

   PANA_UNKNOWN_SESSION_ID                 5002
      The message contained an unknown Session-Id.  A PANA message
      indicating this error MUST include rules given below.  If RT expires before the unknown Session-Id AVP
      within a Failed-AVP AVP.

   PANA_INVALID_AVP_DATA                   5004

      The message contained an AVP with an invalid value in its data
      portion.  A PANA message indicating this error MUST include
   exchange terminates, the
      offending AVPs within sender recomputes RT and retransmits the
   message.

   Each of the computations of a Failed-AVP AVP.

   PANA_MISSING_AVP                        5005

      The message did not contain an AVP that new RT include a randomization factor
   (RAND), which is required by the message
      type definition.  If this value a random number chosen with a uniform distribution
   between -0.1 and +0.1.  The randomization factor is sent in the Result-Code AVP, included to
   minimize synchronization of messages.

   The algorithm for choosing a
      Failed-AVP AVP SHOULD random number does not need to be included in the message.
   cryptographically sound.  The Failed-AVP
      AVP MUST contain an example algorithm SHOULD produce a different
   sequence of random numbers from each invocation.

   RT for the missing AVP complete with first message transmission is based on IRT:

         RT = IRT + RAND*IRT

   RT for each subsequent message transmission is based on the
      Vendor-Id if applicable.  The previous
   value field of RT:

         RT = 2*RTprev + RAND*RTprev

   MRT specifies an upper bound on the missing AVP
      should be value of correct minimum length and contain zeroes.

   PANA_RESOURCES_EXCEEDED                 5006

      A message was received that cannot be authorized because RT (disregarding the
      client
   randomization added by the use of RAND).  If MRT has already expended allowed resources.  An example a value of this
      error condition 0,
   there is no upper limit on the value of RT.  Otherwise:

         if (RT > MRT)
            RT = MRT + RAND*MRT

   MRC specifies an upper bound on the number of times a client that is restricted to one PANA session
      and attempts to establish sender may
   retransmit a second session.  Only message.  Unless MRC is zero, the PAA can
      generate this code.

   PANA_CONTRADICTING_AVPS                 5007

      The PAA message exchange fails
   once the sender has detected AVPs in transmitted the message that contradicted each
      other, and MRC times.

   MRD specifies an upper bound on the length of time a sender may
   retransmit a message.  Unless MRD is not willing to provide service to zero, the client.  One
      or more Failed-AVP AVPs MUST be present, containing message exchange fails
   once MRD seconds have elapsed since the AVPs that
      contradicted each other.  Only client first transmitted the PAA can generate this code.

   PANA_AVP_NOT_ALLOWED                    5008

      A message was received with an AVP that MUST NOT be present.  The
      Failed-AVP AVP MUST be included
   message.

   If both MRC and contain a copy of MRD are non-zero, the
      offending AVP.

   PANA_AVP_OCCURS_TOO_MANY_TIMES          5009

      A message was received that included an AVP that appeared more
      often than permitted exchange fails whenever
   either of the conditions specified in the message definition.  The Failed-AVP
      AVP MUST be included previous two paragraphs are
   met.

   If both MRC and contain a copy of the first instance of MRD are zero, the offending AVP that exceeded client continues to transmit the maximum number of occurrences.

   PANA_UNSUPPORTED_VERSION                5011

      This error is returned when a
   message was received, whose version
      number is unsupported.

   PANA_UNABLE_TO_COMPLY                   5012 until it receives a response.

9.1.  Transmission and Retransmission Parameters

   This error is returned when section presents a request is rejected for unspecified
      reasons.  For example, when an EAP authentication fails at an EAP
      pass-through authenticator without passing an EAP Failure message table of values used to describe the PAA, a Result-Code AVP with this error code is carried in
      the PANA-Error-Request message.

   PANA_INVALID_AVP_LENGTH                 5014

      The message contained an AVP with an invalid length.  The PANA-
      Error-Request
   retransmission behavior of PANA requests that are retransmitted
   (REQ_*) and PANA-Client-Initiation message indicating this error MUST include (PCI_*).  The table shows
   default values.

           Parameter       Default   Description
           ------------------------------------------------
           PCI_IRT           1 sec   Initial PCI timeout.
           PCI_MRT         120 secs  Max PCI timeout value.
           PCI_MRC           0       Configurable.
           PCI_MRD           0       Configurable.

           REQ_IRT           1 sec   Initial Request timeout.
           REQ_MRT          30 secs  Max Request timeout value.
           REQ_MRC          10       Max Request retry attempts.
           REQ_MRD           0       Configurable.

   So for example the
      offending AVPs within a Failed-AVP AVP.

   PANA_INVALID_MESSAGE_LENGTH             5015

      This error is returned when a first RT for the PBR message is received with an invalid
      message length.

   PANA_PROTECTION_CAPABILITY_UNSUPPORTED  5016 calculated using
   REQ_IRT as the IRT:

           RT = REQ_IRT + RAND*REQ_IRT

10.  IANA Considerations

   This error is returned when section provides guidance to the PaC receives a PANA-Bind-Request
      message with a Protection-Capability AVP and a valid AUTH AVP but
      does not support Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the protection capability specified PANA
   protocol, in accordance with BCP 26 [IANA].  The following policies
   are used here with the
      Protection-Capability AVP.  Only the PaC can generate this code.

   PANA_PPAC_CAPABILITY_UNSUPPORTED  5017 meanings defined in BCP 26: "Private Use",
   "First Come First Served", "Expert Review", "Specification Required",
   "IETF Consensus", "Standards Action".

   This error is returned when there is no match between section explains the list of
      PPAC methods offered criteria to be used by the PAA and the ones available on the PaC.
      Only the PaC can generate IANA for
   assignment of numbers within namespaces defined within this code.

8.17.  Session-Id AVP

   All messages pertaining to a specific PANA session MUST include document.

   For registration requests where a
   Session-Id AVP (AVP Code 17) which carries 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 PAA-assigned fixed
   session identifier value throughout successor designated by the lifetime 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 session.  When
   present, notice of the Session-Id AVP MUST appear immediately following decision to the PANA header.

   The Session-Id MUST WG mailing list or its
   successor.  A denial notice must be globally and eternally unique, as justified by an explanation and,
   in the cases where it is meant possible, concrete suggestions on how the
   request can be modified so as to identify a become acceptable.

10.1.  PANA session without reference to any other
   information, UDP Port Number

   PANA uses one well-known UDP port number (Section 4.1, Section 4.3
   and may be needed Section 6.1), which needs to correlate historical authentication
   information with accounting information.  The PANA Session-Id AVP has be assigned by the same format as IANA.

10.2.  PANA Message Header

   As defined in Section 6.2, the Diameter Session-Id AVP [RFC3588].

8.18.  Session-Lifetime AVP

   The Session-Lifetime AVP (AVP Code 18) PANA message header contains two
   fields that requires IANA namespace management; the number of seconds
   remaining before the current session is considered expired.  The AVP
   data is of type Unsigned32.

8.19.  Termination-Cause AVP Version, Message
   Type and Flags fields.

10.2.1.  Version

   The Termination-Cause AVP (AVP Code 19) Version namespace is used for indicating the
   reason why a session is terminated by the requester.  The AVP data is
   of type Enumerated. to identify PANA versions.  The following Termination-Cause data Version
   values are
   used with PANA.

   LOGOUT                   1  (PaC -> PAA)

      The client initiated a disconnect

   ADMINISTRATIVE           4  (PAA -> PaC) assigned by Standards Action [IANA].  This document
   defines the Version 1.

10.2.2.  Message Type

   The client was not granted access, or was disconnected, due Message Type namespace is used to
      administrative reasons.

   SESSION_TIMEOUT          8  (PAA -> PaC)

      The session has timed out, and service has been terminated.

9.  Retransmission Timers

   The identify PANA protocol provides retransmissions messages.  Values
   0-65,519 are for the PANA-Client-
   Initiation permanent, standard message and all request messages, with types, allocated by IETF
   Consensus [IANA].  This document defines the exception that Message Types 1-9.  See
   Section 7.1 through Section 7.17 for the PANA-Start-Answer message is retransmitted instead assignment of the PANA-
   Start-Request message namespace
   in stateless handshake.

   PANA retransmission timers this specification.

   The values 65,520 and 65,535 (hexadecimal values 0xfff0 - 0xffff) are based on
   reserved for experimental messages.  As these codes are only for
   experimental and testing purposes, no guarantee is made for
   interoperability between the model used communicating PaC and PAA using
   experimental commands, as outlined in DHCPv6
   [RFC3315].  Variables used here [IANA-EXP].

10.2.3.  Flags

   There are also borrowed from this
   specification. 16 bits in the Flags field of the PANA is a request response like protocol.  The message exchange terminates when either header.
   This document assigns bit 0 ('R'equest).  The remaining bits MUST
   only be assigned via a Standards Action [IANA].

10.3.  AVP Header

   As defined in Section 6.3, the request sender
   successfully receives AVP header contains three fields that
   requires IANA namespace management; the appropriate answer, or when AVP Code, AVP Flags and
   Vendor-Id fields where only the message
   exchange AVP Code and AVP Flags create new
   namespaces.

10.3.1.  AVP Code

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

   AVP Code 0 is not used.  This document defines the
   following variables:

         RT     Retransmission timeout

         IRT    Initial retransmission time

         MRC    Maximum retransmission count

         MRT    Maximum retransmission time

         MRD    Maximum retransmission duration

         RAND   Randomization factor

   With each message transmission or retransmission, AVP Codes 1-10.
   See Section 8.1 through Section 8.10 for the sender sets RT
   according to assignment of the rules given below.  If RT expires before
   namespace in this specification.

   AVPs may be allocated following Designated Expert with Specification
   Required [IANA] or Standards Action.  AVPs with 'M' bit set MUST be
   allocated by Standards Action.

   Note that PANA defines a mechanism for Vendor-Specific AVPs, where
   the message
   exchange terminates, Vendor-Id field in the sender recomputes RT AVP header is set to a non-zero value.
   Vendor-Specific AVPs codes are for Private Use and retransmits the
   message.

   Each should be
   encouraged instead of the computations allocation of a new RT include a randomization factor
   (RAND), which global attribute types, for
   functions specific only to one vendor's implementation of PANA, where
   no interoperability is deemed useful.  Where a random number chosen with a uniform distribution
   between -0.1 and +0.1.  The randomization factor Vendor-Specific AVP is included to
   minimize synchronization
   implemented by more than one vendor, allocation of messages.

   The algorithm for choosing a random number does not need to global AVPs should
   be
   cryptographically sound.  The algorithm SHOULD produce a different
   sequence of random numbers from each invocation.

   RT for the first message transmission is based on IRT:

         RT = IRT + RAND*IRT
   RT for each subsequent message transmission is based on the previous
   value of RT:

         RT = 2*RTprev + RAND*RTprev

   MRT specifies an upper bound on encouraged instead.

10.3.2.  Flags

   There are 16 bits in the value AVP Flags field of RT (disregarding the
   randomization added by the use of RAND).  If MRT has 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 value Standards Action .

10.4.  AVP Values

   Certain AVPs in PANA define a list of 0,
   there is no upper limit on values with various meanings.
   For attributes other than those specified in this section, adding
   additional values to the value of RT.  Otherwise:

         if (RT > MRT)
            RT = MRT + RAND*MRT

   MRC specifies an upper bound list can be done on the number of times a sender may
   retransmit a message.  Unless MRC is zero, the message exchange fails
   once First Come, First
   Served basis by IANA [IANA].

10.4.1.  Result-Code AVP Values

   As defined in Section 8.8.1 and Section 8.8.2 the sender has transmitted Result-Code AVP
   (AVP Code 8) defines the message MRC times.

   MRD specifies an upper bound on the length of time a sender may
   retransmit a message.  Unless MRD is zero, the message exchange fails
   once MRD seconds have elapsed since values 0-3 and 1001-1015.

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

10.4.2.  Termination-Cause AVP Values

   As defined in Section 8.10, the client first transmitted Termination-Cause AVP (AVP Code 10)
   defines the
   message.

   If both MRC values 1, 4 and MRD 8.

   All remaining values are non-zero, available for assignment via IETF Consensus
   [IANA].

11.  Security Considerations

   The PANA protocol defines a UDP-based EAP encapsulation that runs
   between two IP-enabled nodes on the message exchange fails whenever
   either same IP link.  Various security
   threats that are relevant to a protocol of the conditions specified this nature are outlined
   in [RFC4016].  Security considerations stemming from the previous two paragraphs are
   met.

   If both MRC use of EAP
   and MRD EAP methods are zero, discussed in [RFC3748] [I-D.ietf-eap-keying].
   This section provides a discussion on the client continues security-related issues
   that are related to transmit the
   message until it receives a response.

9.1.  Transmission PANA framework and Retransmission Parameters

   This section presents protocol design.

   An important element in assessing security of PANA design and
   deployment in a table network is the presence of values used to describe lower-layer (physical and
   link-layer) security.  In the message
   retransmission behavior context of PANA requests this document, lower-layers
   are said to be secure if they can prevent eavesdropping and answers that spoofing
   of packets.  Examples of such networks are
   retransmitted (REQ_*) physically-secured DSL
   networks and PANA-Client-Initiation message (PCI_*).
   The table shows default values.

           Parameter       Default   Description
           ------------------------------------------------
           PCI_IRT           1 sec   Initial PCI timeout.
           PCI_MRT         120 secs  Max PCI timeout value.
           PCI_MRC           0       Configurable.
           PCI_MRD           0       Configurable.

           REQ_IRT           1 sec   Initial Request timeout.
           REQ_MRT          30 secs  Max Request timeout value.
           REQ_MRC          10       Max Request retry attempts.
           REQ_MRD           0       Configurable.

   So for example the first RT for 3GPP2 networks with cryptographically-secured cdma2000
   link-layer.  In these examples, the PBR message lower-layer security is calculated using
   REQ_IRT as enabled
   even before running the IRT:

           RT = REQ_IRT + RAND*REQ_IRT

10.  IANA Considerations

   This section provides guidance to first PANA-based authentication.  In the Internet Assigned Numbers
   Authority (IANA) regarding registration
   absence of values related such a pre-established secure channel, one needs to the PANA
   protocol, be
   created in accordance with BCP 26 [IANA].  The following policies
   are used here conjunction 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 PANA using a link-layer or network-layer
   cryptographic mechanism (e.g., IPsec).

11.1.  General Security Measures

   PANA provides multiple mechanisms to be used secure a PANA session.

   PANA messages carry sequence numbers, which are monotonically
   incremented by the IANA for
   assignment of 1 with every new request message.  These numbers within namespaces defined within this document.

   For registration requests where a Designated Expert should be
   consulted, are
   randomly initialized at the responsible IESG area director should appoint beginning of the
   Designated Expert.  For Designated Expert with Specification
   Required, session, and verified
   against expected numbers upon receipt.  A message whose sequence
   number is different than the request expected one is posted silently discarded.  In
   addition to the PANA WG mailing list (or, if
   it has been disbanded, a successor designated by the Area Director)
   for comment accomplishing orderly delivery of EAP messages and review,
   duplicate elimination, this scheme also helps prevent an adversary
   spoof messages to disturb ongoing PANA and MUST include a pointer EAP sessions unless it can
   also eavesdrop to a public
   specification.  Before a period of 30 days has passed, the Designated
   Expert will either approve or deny synchronize on the registration expected sequence number.
   Furthermore, impact of replay attacks is reduced as any stale message
   (i.e., a request or answer with an unexpected sequence number) and
   any duplicate answer are immediately discarded, and
   publish a notice duplicate
   request can trigger transmission of the decision cached answer (i.e., no need
   to process the request and generate a new answer).

   The PANA WG mailing list or its
   successor.  A denial notice must be justified by an explanation and,
   in the cases where it framework defines EP which is possible, concrete suggestions ideally located on how a network
   device that can filter traffic from the
   request PaCs before the traffic
   enters the Internet/intranet.  A set of filters can be modified so used to
   discard unauthorized packets, such as a PANA-Start-Request message
   that is received from the segment of the access network where only
   the PaCs are supposed to become acceptable.

10.1.  PANA UDP Port Number

   PANA uses one well-known UDP port number (Section 4.1, Section 4.3 be connected.

   The protocol also provides authentication and Section 6.1), which needs integrity protection to be assigned by the IANA.

10.2.
   PANA Header

   As defined in Section 6.2, messages when the used EAP method can generate cryptographic
   session keys.  A PANA header contains two fields that
   requires IANA namespace management; the Message Type and Flags field.

10.2.1.  Message Type

   The Message Type namespace SA is used to identify PANA messages.  Values
   0-65,533 are for permanent, standard message types, allocated by IETF
   Consensus [IANA].  This document defines the Message Types 1-9.  See
   Section 7.1 through Section 7.17 for generated based on the assignment of MSK exported by
   the namespace
   in this specification.

   The values 65,534 and 65,535 (hexadecimal values 0xfffe - 0xffff) are
   reserved for experimental messages.  As these codes are only for
   experimental and testing purposes, no guarantee EAP method.  This SA is made used for
   interoperability between generating an AUTH AVP to
   protect the communicating PaC PANA message header and PAA using
   experimental commands, payload (including the complete
   EAP message).

   The cryptographic protection prevents an adversary from acting as outlined in [IANA-EXP].

10.2.2.  Flags

   There are 16 bits in a
   man-in-the-middle, injecting messages, replaying messages and
   modifying the Flags field content of the PANA header.  This
   document assigns bit 0 ('R'equest), bit 1 (state'L'ess handshake). exchanged messages.  Any packet that
   fails to pass the AUTH verification is silently discarded.  The remaining bits MUST only
   earliest this protection can be assigned via a Standards Action
   [IANA].

10.3.  AVP Header

   As defined in Section 6.3, enabled is when the AVP header contains three fields very first
   PANA-Bind-Request message that
   requires IANA namespace management; the AVP Code, AVP Flags and
   Vendor-Id fields where only signals a successful authentication is
   generated.  Starting with these messages, any subsequent PANA message
   until the AVP Code and AVP Flags create new
   namespaces.

10.3.1.  AVP Code session gets torn down can be cryptographically protected.

   The AVP Code namespace lifetime of the PANA SA is used set to identify attributes.  There are
   multiple namespaces.  Vendors can have their own AVP Codes namespace PANA session lifetime which will be identified is
   bounded 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 authorization lifetime granted by the authentication
   server.  An implementation MAY add a Vendor-ID value of zero (0) identifies tolerance period to that value.
   Unless the IETF IANA
   controlled AVP Codes namespace.  The AVP Codes and sometimes also
   possible values in an AVP are controlled and maintained PANA session is extended by IANA.

   AVP Code 0 executing another EAP
   authentication, the PANA SA is not used.  This document defines removed when the AVP Codes 1-19.
   See Section 8.1 through Section 8.19 for current session
   expires.

   The ability to use cryptographic protection within PANA is determined
   by the assignment of used EAP method, which is generally dictated by the
   namespace in this specification.

   AVPs may be allocated following Designated Expert with Specification
   Required [IANA].  Release deployment
   environment.  Insecure lower-layers necessitate use of blocks key-generating
   EAP methods.  In networks where lower-layers are already secured,
   cryptographic protection 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 messages is set not necessary.

11.2.  Handshake

   The handshake phase is vulnerable to a non-zero value.
   Vendor-Specific AVPs codes spoofing attacks as these
   messages are for Private Use not authenticated and integrity protected.  In order to
   prevent very basic denial-of service attacks an adversary should not
   be
   encouraged instead of allocation of global attribute types, for
   functions specific only able to one vendor's implementation of PANA, where
   no interoperability is deemed useful.  Where a Vendor-Specific AVP cause state creation by sending PANA-Client-Initiation
   messages to the PAA.  This protection is
   implemented achieved by more than one vendor, allocation allowing the
   responder (PAA) to create as less amount of global AVPs should
   be encouraged instead.

10.3.2.  Flags

   There are 16 bits state as possible in the AVP Flags field
   first round of the AVP header, defined message exchange.  However, it is difficult to prevent
   all spoofing attacks 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 .

10.4. the handshake phase entirely.

   In networks where lower-layers are not secured prior to running PANA,
   the capability discovery enabled through inclusion of an Algorithm
   AVP Values

   Certain AVPs in PANA define a list PANA-Start-Request message is susceptible to spoofing
   leading to denial-of service attacks.  Therefore, usage 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 [IANA].

10.4.1.  Post-PANA-Address-Configuration AVP Values

   As defined in Section 8.12, the Post-PANA-Address-Configuration AVP
   (AVP Code 12) defines
   during the bits 0 ('N': no configuration), 1 ('F':
   DHCPv4), 2 ('S': DHCPv6), 3 ('A' stateless autoconfiguration), 4
   ('T': DHCPv4 with IPsec tunnel mode) and 5 ('I': IKEv2).

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

10.4.2.  Protection-Capability AVP Values

   As defined handshake phase in Section 8.13, the Protection-Capability such insecure networks is NOT
   RECOMMENDED.  The same AVP (AVP Code
   13) defines is delivered via an integrity-protected
   PANA-Bind-Request upon successful authentication.

11.3.  EAP Methods

   Eavesdropping EAP messages might cause problems when the values 0 EAP method
   is weak and 1.

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

10.4.3.  Result-Code AVP Values

   As defined in Section 8.16.1 and Section 8.16.2 the Result-Code AVP
   (AVP Code 16) defines the values 2001, 3001-3002, 3008-3009, 4001,
   5001-5009 and 5011-5017.

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

10.4.4.  Termination-Cause AVP Values

   As defined in Section 8.19, enables dictionary or replay attacks or even allows an
   adversary to learn the Termination-Cause AVP (AVP Code 19)
   defines long-term password directly.  Furthermore, if
   the values 1, 4 and 8.

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

11.  Security Considerations

   The PANA protocol defines a UDP-based optional EAP encapsulation that runs
   between two IP-enabled nodes on Response/Identity payload is used then it allows the same IP link.  Various security
   threats that are relevant
   adversary to a protocol of this nature are outlined
   in [RFC4016].  Security considerations stemming from learn the use identity of EAP
   and the PaC.  In such a case a privacy
   problem is prevalent.

   To prevent these threats, [I-D.ietf-pana-framework] suggests using
   proper EAP methods are discussed in [RFC3748] [I-D.ietf-eap-keying].
   This section provides a discussion for particular environments.  Depending on the security-related issues
   that are related to PANA framework and protocol design.

   An important element in assessing security of PANA design and
   deployment in a network environment an EAP authentication method which supports
   user identity confidentiality, protection against dictionary attacks
   and session key establishment must be used.  It is therefore the presence
   responsibility of lower-layer (physical the network operators and
   link-layer) security.  In users to choose a proper
   EAP method.

11.4.  Cryptographic Keys

   When the context of EAP method exports an MSK, this document, lower-layers
   are said key is used to be secure if they can prevent eavesdropping and spoofing
   of packets.  Examples of such networks are physically-secured DSL
   networks and 3GPP2 networks produce a
   PANA SA with cryptographically-secured cdma2000
   link-layer.  In these examples, the lower-layer security PANA_AUTH_KEY with a distinct key ID.  The PANA_AUTH_KEY
   is enabled
   even before running unique to the first PANA session, and takes PANA-based authentication.  In nonce values into
   computation to cryptographically separate itself from the
   absence MSK.

   The PANA_AUTH_KEY is solely used for authentication and integrity
   protection of such a pre-established secure channel, one needs to be
   created in conjunction with PANA using a link-layer or network-layer
   cryptographic mechanism (e.g., IPsec).

11.1.  General Security Measures

   PANA provides multiple mechanisms to secure a the PANA messages within the designated session.

   The PANA messages carry sequence numbers, which are monotonically
   incremented SA lifetime is bounded by 1 with every new request message.  These numbers are
   randomly initialized at the beginning MSK lifetime.  Another
   execution of the session, EAP method yields in a new MSK, and verified
   against expected numbers upon receipt.  A message whose sequence
   number is different than updates the expected one is silently discarded.  In
   addition to accomplishing orderly delivery of EAP messages PANA SA,
   PANA_AUTH_KEY and
   duplicate elimination, this scheme also helps prevent an adversary
   spoof messages key ID.

11.5.  Per-packet Ciphering

   Networks that are not secured at the lower-layers prior to disturb ongoing running
   PANA and EAP sessions unless it can
   also eavesdrop to synchronize rely on the expected sequence number.
   Furthermore, impact enabling per-packet data traffic ciphering upon
   successful PANA SA establishment.  The PANA framework allows
   generation of replay attacks is reduced as any stale message
   (i.e., a request or answer with an unexpected sequence number) and
   any duplicate answer are immediately discarded, cryptographic keys from the PANA SA and a duplicate
   request can trigger transmission of use the cached answer (i.e., no need keys
   with a secure association protocol to process enable per-packet cryptographic
   protection such as link-layer or IPsec-based ciphering
   [I-D.ietf-pana-ipsec].  These mechanisms ultimately establish a
   cryptographic binding between the request data traffic generated by and generate a new answer).

   The PANA framework defines EP which is ideally located on for a network
   device that can filter traffic from
   client and the PaCs before authenticated identity of the client.  Data traffic
   enters the Internet/intranet.  A set of filters can
   must be minimally data origin authenticated, replay and integrity
   protected, and optionally encrypted.  How cryptographic keys are
   generated from the PANA SA and used to
   discard unauthorized packets, such as with a PANA-Start-Request message
   that secure association
   protocol is received from outside the segment scope of this document.

11.6.  PAA-to-EP Communication

   The PANA framework allows separation of PAA from EP.  SNMPv3
   [I-D.ietf-pana-snmp] MAY be used between the access network where only PAA and EP for
   provisioning authorized PaC information on the PaCs are supposed to EP.  This exchange
   MUST be connected.

   The protocol also provides authentication and always physically or cryptographically protected for
   authentication, integrity protection to and replay protection.

11.7.  Liveness Test

   A PANA messages when the used session is associated with a session lifetime.  The session is
   terminated unless it is refreshed by a new round of EAP method
   authentication before it expires.  Therefore, at the latest a
   disconnected client can generate cryptographic be detected when its session keys. expires.  A
   disconnect may also be detected earlier by using PANA SA is ping messages.
   A request message can be generated based on the MSK exported by
   the EAP method.  This SA is used for generating an AUTH AVP to
   protect the PANA header either PaC or PAA at any time
   and payload (including the complete EAP
   message).

   The cryptographic protection prevents peer must respond with an adversary from acting as a
   man-in-the-middle, injecting messages, replaying messages and
   modifying the content answer message.  A successful
   round-trip of the exchanged messages.  Any packet this exchange is a simple verification that
   fails to pass the AUTH verification peer is silently discarded.  The
   earliest this protection
   alive.

   This test can be enabled is engaged when the very first PANA-
   Bind-Request message there is a possibility that signals the peer
   might have disconnected (e.g., after the discontinuation of data
   traffic for an extended period of time).  Periodic use of this
   exchange as a successful authentication keep-alive requires additional care as it might result
   in congestion and hence false alarms.

   This exchange is
   generated.  Starting cryptographically protected when a PANA SA is
   available in order to prevent threats associated with these messages, any subsequent the abuse of
   this functionality.

   Any valid PANA answer message received in response to a recently sent
   request message
   until the session gets torn down can be cryptographically protected.

   The PANA SA enables authenticated and integrity protected exchange taken as an indication of
   the device ID information between the peer's liveness.
   The PaC and PAA.  This ensures
   there were no man-in-the-middle during or PAA MAY forgo sending an explicit PANA-Ping-Request if a
   recent exchange has already confirmed that the peer is alive.

11.8.  IP Address Spoofing

   PANA authentication.

   The lifetime does not provide any means to prove ownership of the PANA SA is set to PANA session lifetime which is
   bounded by the authorization lifetime granted IP address
   presented by the authentication
   server.  An implementation MAY add PaC.  Hence, an authorized PaC can launch a tolerance period to that value.
   Unless the PANA session is extended redirect
   attack by executing another EAP
   authentication, the PANA SA is removed when spoofing a victim's IP address.  This problem and its
   solution are outside the current session
   expires. scope of PANA.

11.9.  Early Termination of a Session

   The ability to use cryptographic protection within PANA is determined
   by protocol supports the used EAP method, which is generally dictated by ability for both the deployment
   environment.  Insecure lower-layers necessitate use of key-generating
   EAP methods.  In networks where lower-layers are already secured,
   cryptographic protection of PANA messages is not necessary.

11.2.  Handshake

   The handshake phase is vulnerable to spoofing attacks as these
   messages are not authenticated PaC and integrity protected.  In order to
   prevent very basic denial-of service attacks an adversary should not
   be able to cause state creation by sending PANA-Client-Initiation
   messages the PAA
   to transmit a tear-down message before the PAA. session lifetime expires.
   This protection is achieved by using message causes state removal, a cookie-
   based scheme (similar to [RFC2522] which allows the responder (PAA)
   to be stateless in the first round stop of message exchange.  However, it
   is difficult to prevent all spoofing attacks in the handshake phase
   entirely.

   In networks where lower-layers are not secured prior to running PANA, the capability discovery enabled through inclusion of Protection-
   Capability accounting procedure
   and Post-PANA-Address-Configuration AVPs in a PANA-Start-
   Request removes the installed per-PaC state on the EP(s).  This message
   is susceptible to spoofing leading to denial-of
   service attacks.  Therefore, usage of these AVPs during the handshake
   phase in such insecure networks is NOT RECOMMENDED.  The same AVPs
   are delivered via an integrity-protected PANA-Bind-Request upon
   successful authentication.

11.3.  EAP Methods

   Eavesdropping EAP messages might cause problems cryptographically protected when the EAP method
   is weak and enables dictionary or replay attacks or even allows an
   adversary to learn the long-term password directly.  Furthermore, if
   the optional EAP Response/Identity payload is used then it allows the
   adversary to learn the identity of the PaC.  In such a case a privacy
   problem is prevalent.

   To prevent these threats, [I-D.ietf-pana-framework] suggests using
   proper EAP methods for particular environments.  Depending on the
   deployment environment an EAP authentication method which supports
   user identity confidentiality, protection against dictionary attacks
   and session key establishment must be used.  It is therefore the
   responsibility of the network operators and users to choose a proper
   EAP method.

11.4.  Cryptographic Keys

   When the EAP method exports an MSK, this key is used to produce a PANA SA with PANA_AUTH_KEY with a distinct key ID.  The PANA_AUTH_KEY is unique to the PANA session, and takes PANA-based nonce values into
   computation present.

12.  Acknowledgments

   We would like to cryptographically separate itself from the MSK.

   The PANA_AUTH_KEY is solely used for authentication and integrity
   protection of the PANA messages within the designated session.

   The PANA SA lifetime is bounded by the MSK lifetime.  Another
   execution of EAP method yields in a new MSK, and updates the PANA SA,
   PANA_AUTH_KEY and key ID.

   When link-layer or network-layer ciphering [I-D.ietf-pana-ipsec] is
   enabled as a result of successful PANA authentication, a PaC-EP-
   Master-Key is generated for each EP from the MSK, session identifier,
   key identifier, and the EP device identifier.  The PaC-EP-Master-Key
   derivation algorithm defined in Section 5.6 ensures cryptographic
   independence among different PaC-EP-Master-Keys.

   The lifetime of a PaC-EP-Master-Key is bounded by the lifetime of the
   PANA SA.  This key may be used with a secure association protocol
   [RFC4306] to produce further cipher-specific and transient keys.

11.5.  Per-packet Ciphering

   Networks that are not secured at the lower-layers prior to running
   PANA can rely on enabling per-packet data traffic ciphering upon
   successful PANA session establishment.  The PANA framework allows
   generation of a PaC-EP-Master-Key from an MSK for using with a per-
   packet protection mechanism, such as link-layer or IPsec-based
   ciphering [I-D.ietf-pana-ipsec].  In case the master key is not
   readily useful to the ciphering mechanism, an additional secure
   association protocol [RFC4306] may be needed to produce the required
   keying material.  These mechanisms ultimately establish a
   cryptographic binding between the data traffic generated by and for a
   client and the authenticated identity of the client.  Data traffic
   must be minimally data origin authenticated, replay and integrity
   protected, and optionally encrypted.

11.6.  PAA-to-EP Communication

   The PANA framework allows separation of PAA from EP.  SNMPv3
   [I-D.ietf-pana-snmp] MAY be used between the PAA and EP for
   provisioning authorized PaC information on the EP.  This exchange
   MUST be always physically or cryptographically protected for
   authentication, integrity and replay protection.  It MUST also be
   privacy-protected when a PaC-EP-Master-Key for per-packet ciphering
   is transmitted to the EP.

   The PaC-EP-Master-Key MUST be unique to the PaC and EP pair.  The
   session identifier and the device identifier of the EP are taken into
   computation for achieving this effect [I-D.ietf-pana-ipsec].
   Compromise of an EP does not automatically lead to compromise of
   another EP or the PAA.

11.7.  Liveness Test

   A PANA session is associated with a session lifetime.  The session is
   terminated unless it is refreshed by a new round of EAP
   authentication before it expires.  Therefore, at the latest a
   disconnected client can be detected when its session expires.  A
   disconnect may also be detected earlier by using PANA ping messages.
   A request message can be generated by either PaC or PAA at any time
   and the peer must respond with an answer message.  A successful
   round-trip of this exchange is a simple verification that the peer is
   alive.

   This test can be engaged when there is a possibility that the peer
   might have disconnected (e.g., after the discontinuation of data
   traffic for an extended period of time).  Periodic use of this
   exchange as a keep-alive requires additional care as it might result
   in congestion and hence false alarms.

   This exchange is cryptographically protected when a PANA SA is
   available in order to prevent threats associated with the abuse of
   this functionality.

   Any valid PANA answer message received in response to a recently sent
   request message can be taken as an indication of peer's liveness.
   The PaC or PAA MAY forgo sending an explicit PANA-Ping-Request if a
   recent exchange has already confirmed that the peer is alive.

11.8.  Updating PaC's IP Address

   There is no way to prove the ownership of the IP address presented by
   the PaC.  Hence an authorized PaC can launch a redirect attack by
   spoofing a victim's IP address.

11.9.  Early Termination of a Session

   The PANA protocol supports the ability for both the PaC and the PAA
   to transmit a tear-down message before the session lifetime expires.
   This message causes state removal, a stop of the accounting procedure
   and removes the installed per-PaC state on the EP(s).  This message
   is cryptographically protected when PANA SA is present.

12.  Acknowledgments

   We would like to thank Jari Arkko, Mohan Parthasarathy, Julien
   Bournelle, Rafael Marin Lopez, Pasi Eronen, Randy Turner, Erik
   Nordmark, Lionel Morand, Avi Lior, Susan Thomson, Giaretta Gerardo,
   Joseph Salowey, Sasikanth Bharadwaj, Spencer Dawkins, Tom Yu, Bernard
   Aboba and all members of the PANA working group for their valuable
   comments to this document.

13.  References

13.1.  Normative References

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC2279]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", RFC 2279, January 1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, December 1998.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3456]  Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic
              Host Configuration Protocol (DHCPv4) Configuration of
              IPsec Tunnel Mode", RFC 3456, January 2003.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [I-D.ietf-ltru-registry]
              Phillips, A. and M. Davis, "Tags for Identifying
              Languages", draft-ietf-ltru-registry-14 (work in
              progress), October 2005.

   [I-D.ietf-dhc-paa-option]
              Kumar, S., "DHCP options for PANA Authentication Agents",
              draft-ietf-dhc-paa-option-03 (work in progress),
              July 2006.

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

13.2.  Informative References

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2522]  Karn, P. and W. Simpson, "Photuris: Session-Key Management
              Protocol", RFC 2522, March 1999.

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927,
              May 2005.

   [RFC4016]  Parthasarathy, M., "Protocol for Carrying Authentication
              and Network Access (PANA) Threat Analysis and Security
              Requirements", RFC 4016, March 2005.

   [RFC4058]  Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang,
              "Protocol for Carrying Authentication for Network Access
              (PANA) Requirements", RFC 4058, May 2005.

   [RFC4137]  Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
              "State Machines for Extensible Authentication Protocol
              (EAP) Peer and Authenticator", RFC 4137, August 2005.

   [RFC4284]  Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity
              Selection Hints for the Extensible Authentication Protocol
              (EAP)", RFC 4284, January 2006.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC4307]  Schiller, J., "Cryptographic Algorithms for Use in the
              Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
              December 2005.

   [I-D.ietf-eap-keying]
              Aboba, B., "Extensible Authentication Protocol (EAP) Key
              Management Framework", draft-ietf-eap-keying-14 (work in
              progress), June 2006.

   [I-D.ietf-pana-ipsec]
              Parthasarathy, M., "PANA Enabling IPsec based Access
              Control", draft-ietf-pana-ipsec-07 (work in progress),
              July 2005.

   [I-D.ietf-pana-framework]
              Jayaraman, P., "PANA Framework",
              draft-ietf-pana-framework-06 (work in progress),
              March 2006.

   [I-D.ietf-pana-snmp]
              Mghazli, Y., "SNMP usage for PAA-EP interface",
              draft-ietf-pana-snmp-06 (work in progress), June 2006.

   [I-D.ietf-mobike-protocol]
              Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", draft-ietf-mobike-protocol-08 (work in
              progress), February 2006.

   [ianaweb]  IANA, "Number assignment",  http://www.iana.org.

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

Appendix A.  IP Address Configuration

   The PaC configures an IP address before the PANA exchange begins.
   This address is called a pre-PANA address (PRPA).  After a successful
   authentication, the client may have to configure a new IP address for
   communication with other nodes, if the PRPA is a local-use (e.g., a
   link-local or private address) or a temporarily allocated IP address.
   This IP address is called a post-PANA address (POPA).  An operator
   might choose allocating a POPA only after successful PANA
   authorization either to prevent waste of premium (e.g., globally
   routable) IP resources until the client is authorized, or to enable
   client identity based address assignment.

   There are different methods by which a PRPA can be configured.

   1. In some deployments (e.g., DSL networks) the PaC may be statically
      configured with an IP address.  This address can be used as a
      PRPA.

   2. In IPv4, some clients attempt to configure an address dynamically
      using DHCP [RFC2131].  If they are unable to configure an address
      using DHCP, they can configure a link-local address using
      [RFC3927].

      When the network access provider is able to run a DHCP server on
      the access link, the client would configure the PRPA using DHCP.
      This address may be from a private address pool [RFC1918].  Also,
      the lease time on the address may vary.  For example, a PRPA
      configured solely for running PANA can have a short lease time.
      The PRPA may be used for local-use only (i.e., only for on-link
      communication, such as for PANA and IPsec tunneling with EP), or
      also for ultimate end-to-end data communication.

      In case there is no running DHCP server on the link, the client
      might fall back to configuring a PRPA via zeroconfiguration
      technique [RFC3927].  This yields a long-term address that can
      only be used for on-link communication.  (Note: At time of this
      writing, the zeroconfiguration technique is not widely implemented
      in routers.)

   3. In IPv6, clients automatically configure a link-local address
      [RFC2462] when they initialize an interface.  Additionally, they
      may also configure non-link-local address(es) when DHCP or router
      advertisements with prefixes are made available to the them.

   In case PAA is not on the same IP subnet as the PaCs are, the
   deployment needs to ensure that a non-link-local PRPA is configurable
   by the clients.

   When a PRPA is configured, the client starts the PANA exchange.  By
   that time, a dual stacked client might have configured both an IPv4
   address and an IPv6 address as PRPAs.  Regardless of whether the PaC
   has both IPv4 and IPv6 PRPAs or only one of those, only one PANA run
   is required.  When a dual-stack PaC or PAA initiates PANA
   authentication, it chooses either IPv4 or IPv6 where the choice is
   made depending on the deployment.

   When the client successfully authenticates to the network, it may be
   required to configure POPAs for its subsequent data communication
   with the other nodes.

   If the client is already configured with an address that can be used
   with data communication, it is not required to configure a POPA.
   Otherwise, the PANA-Bind-Request message allows the PAA to indicate
   the available configuration methods to the PaC.  The PaC can choose
   one of the methods and act accordingly.

   1. If the network relies on physical or link layer security, the PaC
      can configure a POPA using DHCP [RFC2131] [RFC3315] or using IPv6
      stateless auto-configuration [RFC2461].  An IPv4 PRPA SHOULD be
      unconfigured when the POPA is configured to prevent IPv4 address
      selection problem [RFC3927].

      If the PaC is a dual-stacked node, it can configure both IPv4 thank Mark Townsley, Jari Arkko, Mohan
   Parthasarathy, Julien Bournelle, Rafael Marin Lopez, Pasi Eronen,
   Randy Turner, Erik Nordmark, Lionel Morand, Avi Lior, Susan Thomson,
   Giaretta Gerardo, Joseph Salowey, Sasikanth Bharadwaj, Spencer
   Dawkins, Tom Yu, Bernard Aboba and
      IPv6 type POPAs.  The available POPA configuration methods are
      indicated within PANA.

   2. If the network uses IPsec for protecting the traffic on all members of the link
      subsequent to PANA authentication [I-D.ietf-pana-ipsec], the PaC
      would use the PRPA as the outer address of IPsec tunnel mode SA
      (IPsec-TOA).  The PaC also needs to configure an inner address
      (IPsec-TIA).  There are different ways working
   group for their valuable comments to configure an IPsec-TIA
      which are indicated in a PANA-Bind-Request message.

      When an IPv4 PRPA is configured, the same address may be used as
      both IPsec-TOA and IPsec-TIA.  In this case, a POPA is not
      configured.  Alternatively, an IPsec-TIA can be obtained via the
      configuration method available within [RFC3456] document.

13.  References

13.1.  Normative References

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for IPv4,
      [RFC4307] Message Authentication", RFC 2104,
              February 1997.

   [RFC2119]  Bradner, S., "Key words for both IPv4 and IPv6.  This newly configured address
      constitutes a POPA.  Please refer use in RFCs to [I-D.ietf-pana-ipsec] for
      more details.

      IKEv2 [RFC4307] can enable configuration of one IPv4 IPsec-TIA Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2234]  Crocker, D., Ed. and
      one IPv6 IPsec-TIA P. Overell, "Augmented BNF for the same IPsec tunnel mode SA.  Therefore,
      IKEv2 is recommended Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for handling dual-stacked PaCs where single
      execution of PANA Security", BCP 106, RFC 4086, June 2005.

   [RFC4595]  Maino, F. and IKE is desired.  In this case, D. Black, "Use of IKEv2 in the same IP
      version that has been used Fibre Channel
              Security Association Management Protocol", RFC 4595,
              July 2006.

   [I-D.ietf-dhc-paa-option]
              Morand, L., "DHCP options for PANA is used for IKE, Authentication Agents",
              draft-ietf-dhc-paa-option-04 (work in progress),
              September 2006.

   [IANA]     Narten, T. and the IKE
      entity on the dual-stack PaC will request one or both of IPv4 H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",  BCP 26, RFC 2434,
              October 1998.

13.2.  Informative References

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 IPsec-TIAs from the IKE entity on the EP and obtain the
      one(s) that is/are available on the EP.

   Although there are potentially a number of different ways to
   configure a PRPA, (DHCPv6)", RFC 3315, July 2003.

   [RFC4016]  Parthasarathy, M., "Protocol for Carrying Authentication
              and POPA when necessary, it should be noted that
   the ultimate decision to use one or more of these in a deployment
   depends on the operator.  The decision is dictated by the operator's
   choice of per-packet protection capability (physical Network Access (PANA) Threat Analysis and link-layer
   vs network-layer), PRPA type (local Security
              Requirements", RFC 4016, March 2005.

   [RFC4058]  Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and temporary vs global C. Wang,
              "Protocol for Carrying Authentication for Network Access
              (PANA) Requirements", RFC 4058, May 2005.

   [RFC4137]  Vollbrecht, J., Eronen, P., Petroni, N., and long-
   term), Y. Ohba,
              "State Machines for Extensible Authentication Protocol
              (EAP) Peer and POPA configuration mechanisms available Authenticator", RFC 4137, August 2005.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [I-D.ietf-eap-keying]
              Aboba, B., "Extensible Authentication Protocol (EAP) Key
              Management Framework", draft-ietf-eap-keying-15 (work in
              progress), October 2006.

   [I-D.ietf-pana-ipsec]
              Parthasarathy, M., "PANA Enabling IPsec based Access
              Control", draft-ietf-pana-ipsec-07 (work in progress),
              July 2005.

   [I-D.ietf-pana-framework]
              Jayaraman, P., "Protocol for Carrying Authentication for
              Network Access (PANA) Framework",
              draft-ietf-pana-framework-07 (work in progress),
              August 2006.

   [I-D.ietf-pana-snmp]
              Mghazli, Y., "SNMP usage for PAA-EP interface",
              draft-ietf-pana-snmp-06 (work in the network. progress), June 2006.

   [ianaweb]  IANA, "Number assignment",  http://www.iana.org.

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

Authors' Addresses

   Dan Forsberg
   Nokia Research Center
   P.O. Box 407
   FIN-00045 NOKIA GROUP
   Finland

   Phone: +358 50 4839470
   Email: dan.forsberg@nokia.com

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   1 Telcordia Drive
   Piscataway, NJ  08854
   USA

   Phone: +1 732 699 5305
   Email: yohba@tari.toshiba.com

   Basavaraj Patil
   Nokia
   6000 Connection Dr.
   Irving, TX  75039
   USA

   Phone: +1 972-894-6709
   Email: Basavaraj.Patil@nokia.com

   Hannes Tschofenig
   Siemens Corporate Technology
   Otto-Hahn-Ring 6
   81739 Munich
   Germany

   Email: Hannes.Tschofenig@siemens.com
   Alper E. Yegin
   Samsung Advanced Institute of Technology
   Istanbul,
   Turkey

   Phone: +90 538 719 0181
   Email: alper01.yegin@partner.samsung.com

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society. IETF
   Administrative Support Activity (IASA).