Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6733


Diameter Base Protocol

Part 2 of 5, p. 20 to 57
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 20 
2.  Protocol Overview

   The base Diameter protocol concerns itself with establishing
   connections to peers, capabilities negotiation, how messages are sent
   and routed through peers, and how the connections are eventually torn
   down.  The base protocol also defines certain rules that apply to all
   message exchanges between Diameter nodes.

   Communication between Diameter peers begins with one peer sending a
   message to another Diameter peer.  The set of AVPs included in the
   message is determined by a particular Diameter application.  One AVP
   that is included to reference a user's session is the Session-Id.

   The initial request for authentication and/or authorization of a user
   would include the Session-Id AVP.  The Session-Id is then used in all
   subsequent messages to identify the user's session (see Section 8 for

Top      Up      ToC       Page 21 
   more information).  The communicating party may accept the request or
   reject it by returning an answer message with the Result-Code AVP set
   to indicate that an error occurred.  The specific behavior of the
   Diameter server or client receiving a request depends on the Diameter
   application employed.

   Session state (associated with a Session-Id) MUST be freed upon
   receipt of the Session-Termination-Request, Session-Termination-
   Answer, expiration of authorized service time in the Session-Timeout
   AVP, and according to rules established in a particular Diameter

   The base Diameter protocol may be used by itself for accounting
   applications.  For authentication and authorization, it is always
   extended for a particular application.

   Diameter clients MUST support the base protocol, which includes
   accounting.  In addition, they MUST fully support each Diameter
   application that is needed to implement the client's service, e.g.,
   Network Access Server Requirements (NASREQ) [RFC2881] and/or Mobile
   IPv4.  A Diameter client MUST be referred to as "Diameter X Client"
   where X is the application that it supports and not a "Diameter

   Diameter servers MUST support the base protocol, which includes
   accounting.  In addition, they MUST fully support each Diameter
   application that is needed to implement the intended service, e.g.,
   NASREQ and/or Mobile IPv4.  A Diameter server MUST be referred to as
   "Diameter X Server" where X is the application that it supports, and
   not a "Diameter Server".

   Diameter relays and redirect agents are transparent to the Diameter
   applications, but they MUST support the Diameter base protocol, which
   includes accounting, and all Diameter applications.

   Diameter proxies MUST support the base protocol, which includes
   accounting.  In addition, they MUST fully support each Diameter
   application that is needed to implement proxied services, e.g.,
   NASREQ and/or Mobile IPv4.  A Diameter proxy MUST be referred to as
   "Diameter X Proxy" where X is the application which it supports, and
   not a "Diameter Proxy".

Top      Up      ToC       Page 22 
2.1.  Transport

   The Diameter Transport profile is defined in [RFC3539].

   The base Diameter protocol is run on port 3868 for both TCP [RFC0793]
   and SCTP [RFC4960].  For TLS [RFC5246] and Datagram Transport Layer
   Security (DTLS) [RFC6347], a Diameter node that initiates a
   connection prior to any message exchanges MUST run on port 5658.  It
   is assumed that TLS is run on top of TCP when it is used, and DTLS is
   run on top of SCTP when it is used.

   If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
   connections on port 5658 (i.e., the peer complies only with RFC
   3588), then the initiator MAY revert to using TCP or SCTP on port
   3868.  Note that this scheme is kept only for the purpose of backward
   compatibility and that there are inherent security vulnerabilities
   when the initial CER/CEA messages are sent unprotected (see
   Section 5.6).

   Diameter clients MUST support either TCP or SCTP; agents and servers
   SHOULD support both.

   A Diameter node MAY initiate connections from a source port other
   than the one that it declares it accepts incoming connections on, and
   it MUST always be prepared to receive connections on port 3868 for
   TCP or SCTP and port 5658 for TLS/TCP and DTLS/SCTP connections.
   When DNS-based peer discovery (Section 5.2) is used, the port numbers
   received from SRV records take precedence over the default ports
   (3868 and 5658).

   A given Diameter instance of the peer state machine MUST NOT use more
   than one transport connection to communicate with a given peer,
   unless multiple instances exist on the peer, in which, case a
   separate connection per process is allowed.

   When no transport connection exists with a peer, an attempt to
   connect SHOULD be made periodically.  This behavior is handled via
   the Tc timer (see Section 12 for details), whose recommended value is
   30 seconds.  There are certain exceptions to this rule, such as when
   a peer has terminated the transport connection stating that it does
   not wish to communicate.

   When connecting to a peer and either zero or more transports are
   specified, TLS SHOULD be tried first, followed by DTLS, then by TCP,
   and finally by SCTP.  See Section 5.2 for more information on peer

Top      Up      ToC       Page 23 
   Diameter implementations SHOULD be able to interpret ICMP protocol
   port unreachable messages as explicit indications that the server is
   not reachable, subject to security policy on trusting such messages.
   Further guidance regarding the treatment of ICMP errors can be found
   in [RFC5927] and [RFC5461].  Diameter implementations SHOULD also be
   able to interpret a reset from the transport and timed-out connection
   attempts.  If Diameter receives data from the lower layer that cannot
   be parsed or identified as a Diameter error made by the peer, the
   stream is compromised and cannot be recovered.  The transport
   connection MUST be closed using a RESET call (send a TCP RST bit) or
   an SCTP ABORT message (graceful closure is compromised).

2.1.1.  SCTP Guidelines

   Diameter messages SHOULD be mapped into SCTP streams in a way that
   avoids head-of-the-line (HOL) blocking.  Among different ways of
   performing the mapping that fulfill this requirement it is
   RECOMMENDED that a Diameter node send every Diameter message (request
   or response) over stream zero with the unordered flag set.  However,
   Diameter nodes MAY select and implement other design alternatives for
   avoiding HOL blocking such as using multiple streams with the
   unordered flag cleared (as originally instructed in RFC 3588).  On
   the receiving side, a Diameter entity MUST be ready to receive
   Diameter messages over any stream, and it is free to return responses
   over a different stream.  This way, both sides manage the available
   streams in the sending direction, independently of the streams chosen
   by the other side to send a particular Diameter message.  These
   messages can be out-of-order and belong to different Diameter

   Out-of-order delivery has special concerns during a connection
   establishment and termination.  When a connection is established, the
   responder side sends a CEA message and moves to R-Open state as
   specified in Section 5.6.  If an application message is sent shortly
   after the CEA and delivered out-of-order, the initiator side, still
   in Wait-I-CEA state, will discard the application message and close
   the connection.  In order to avoid this race condition, the receiver
   side SHOULD NOT use out-of-order delivery methods until the first
   message has been received from the initiator, proving that it has
   moved to I-Open state.  To trigger such a message, the receiver side
   could send a DWR immediately after sending a CEA.  Upon reception of
   the corresponding DWA, the receiver side should start using out-of-
   order delivery methods to counter the HOL blocking.

   Another race condition may occur when DPR and DPA messages are used.
   Both DPR and DPA are small in size; thus, they may be delivered to
   the peer faster than application messages when an out-of-order
   delivery mechanism is used.  Therefore, it is possible that a DPR/DPA

Top      Up      ToC       Page 24 
   exchange completes while application messages are still in transit,
   resulting in a loss of these messages.  An implementation could
   mitigate this race condition, for example, using timers, and wait for
   a short period of time for pending application level messages to
   arrive before proceeding to disconnect the transport connection.
   Eventually, lost messages are handled by the retransmission mechanism
   described in Section 5.5.4.

   A Diameter agent SHOULD use dedicated payload protocol identifiers
   (PPIDs) for clear text and encrypted SCTP DATA chunks instead of only
   using the unspecified payload protocol identifier (value 0).  For
   this purpose, two PPID values are allocated: the PPID value 46 is for
   Diameter messages in clear text SCTP DATA chunks, and the PPID value
   47 is for Diameter messages in protected DTLS/SCTP DATA chunks.

2.2.  Securing Diameter Messages

   Connections between Diameter peers SHOULD be protected by TLS/TCP and
   DTLS/SCTP.  All Diameter base protocol implementations MUST support
   the use of TLS/TCP and DTLS/SCTP.  If desired, alternative security
   mechanisms that are independent of Diameter, such as IPsec [RFC4301],
   can be deployed to secure connections between peers.  The Diameter
   protocol MUST NOT be used without one of TLS, DTLS, or IPsec.

2.3.  Diameter Application Compliance

   Application Ids are advertised during the capabilities exchange phase
   (see Section 5.3).  Advertising support of an application implies
   that the sender supports the functionality specified in the
   respective Diameter application specification.

   Implementations MAY add arbitrary optional AVPs with the M-bit
   cleared (including vendor-specific AVPs) to a command defined in an
   application, but only if the command's CCF syntax specification
   allows for it.  Please refer to Section 11.1.1 for details.

2.4.  Application Identifiers

   Each Diameter application MUST have an IANA-assigned Application ID.
   The base protocol does not require an Application Id since its
   support is mandatory.  During the capabilities exchange, Diameter
   nodes inform their peers of locally supported applications.
   Furthermore, all Diameter messages contain an Application Id, which
   is used in the message forwarding process.

Top      Up      ToC       Page 25 
   The following Application Id values are defined:

         Diameter common message       0
         Diameter base accounting      3
         Relay                         0xffffffff

   Relay and redirect agents MUST advertise the Relay Application ID,
   while all other Diameter nodes MUST advertise locally supported
   applications.  The receiver of a Capabilities Exchange message
   advertising relay service MUST assume that the sender supports all
   current and future applications.

   Diameter relay and proxy agents are responsible for finding an
   upstream server that supports the application of a particular
   message.  If none can be found, an error message is returned with the

2.5.  Connections vs. Sessions

   This section attempts to provide the reader with an understanding of
   the difference between "connection" and "session", which are terms
   used extensively throughout this document.

   A connection refers to a transport-level connection between two peers
   that is used to send and receive Diameter messages.  A session is a
   logical concept at the application layer that exists between the
   Diameter client and the Diameter server; it is identified via the
   Session-Id AVP.

             +--------+          +-------+          +--------+
             | Client |          | Relay |          | Server |
             +--------+          +-------+          +--------+
                      <---------->       <---------->
                   peer connection A   peer connection B

                              User session x

                Figure 1: Diameter Connections and Sessions

   In the example provided in Figure 1, peer connection A is established
   between the client and the relay.  Peer connection B is established
   between the relay and the server.  User session X spans from the
   client via the relay to the server.  Each "user" of a service causes
   an auth request to be sent, with a unique session identifier.  Once
   accepted by the server, both the client and the server are aware of
   the session.

Top      Up      ToC       Page 26 
   It is important to note that there is no relationship between a
   connection and a session, and that Diameter messages for multiple
   sessions are all multiplexed through a single connection.  Also, note
   that Diameter messages pertaining to the session, both application-
   specific and those that are defined in this document such as ASR/ASA,
   RAR/RAA, and STR/STA, MUST carry the Application Id of the
   application.  Diameter messages pertaining to peer connection
   establishment and maintenance such as CER/CEA, DWR/DWA, and DPR/DPA
   MUST carry an Application Id of zero (0).

2.6.  Peer Table

   The Diameter peer table is used in message forwarding and is
   referenced by the routing table.  A peer table entry contains the
   following fields:

   Host Identity

      Following the conventions described for the DiameterIdentity-
      derived AVP data format in Section 4.3.1, this field contains the
      contents of the Origin-Host (Section 6.3) AVP found in the CER or
      CEA message.


      This is the state of the peer entry, and it MUST match one of the
      values listed in Section 5.6.

   Static or Dynamic

      Specifies whether a peer entry was statically configured or
      dynamically discovered.

   Expiration Time

      Specifies the time at which dynamically discovered peer table
      entries are to be either refreshed or expired.  If public key
      certificates are used for Diameter security (e.g., with TLS), this
      value MUST NOT be greater than the expiry times in the relevant

   TLS/TCP and DTLS/SCTP Enabled

      Specifies whether TLS/TCP and DTLS/SCTP is to be used when
      communicating with the peer.

   Additional security information, when needed (e.g., keys,

Top      Up      ToC       Page 27 
2.7.  Routing Table

   All Realm-Based routing lookups are performed against what is
   commonly known as the routing table (see Section 12).  Each routing
   table entry contains the following fields:

   Realm Name

      This is the field that MUST be used as a primary key in the
      routing table lookups.  Note that some implementations perform
      their lookups based on longest-match-from-the-right on the realm
      rather than requiring an exact match.

   Application Identifier

      An application is identified by an Application Id.  A route entry
      can have a different destination based on the Application Id in
      the message header.  This field MUST be used as a secondary key
      field in routing table lookups.

   Local Action

      The Local Action field is used to identify how a message should be
      treated.  The following actions are supported:

      1.  LOCAL - Diameter messages that can be satisfied locally and do
          not need to be routed to another Diameter entity.

      2.  RELAY - All Diameter messages that fall within this category
          MUST be routed to a next-hop Diameter entity that is indicated
          by the identifier described below.  Routing is done without
          modifying any non-routing AVPs.  See Section 6.1.9 for
          relaying guidelines.

      3.  PROXY - All Diameter messages that fall within this category
          MUST be routed to a next Diameter entity that is indicated by
          the identifier described below.  The local server MAY apply
          its local policies to the message by including new AVPs to the
          message prior to routing.  See Section 6.1.9 for proxying

      4.  REDIRECT - Diameter messages that fall within this category
          MUST have the identity of the home Diameter server(s)
          appended, and returned to the sender of the message.  See
          Section 6.1.8 for redirection guidelines.

Top      Up      ToC       Page 28 
   Server Identifier

      The identity of one or more servers to which the message is to be
      routed.  This identity MUST also be present in the Host Identity
      field of the peer table (Section 2.6).  When the Local Action is
      set to RELAY or PROXY, this field contains the identity of the
      server(s) to which the message MUST be routed.  When the Local
      Action field is set to REDIRECT, this field contains the identity
      of one or more servers to which the message MUST be redirected.

   Static or Dynamic

      Specifies whether a route entry was statically configured or
      dynamically discovered.

   Expiration Time

      Specifies the time at which a dynamically discovered route table
      entry expires.  If public key certificates are used for Diameter
      security (e.g., with TLS), this value MUST NOT be greater than the
      expiry time in the relevant certificates.

   It is important to note that Diameter agents MUST support at least
   one of the LOCAL, RELAY, PROXY, or REDIRECT modes of operation.
   Agents do not need to support all modes of operation in order to
   conform with the protocol specification, but they MUST follow the
   protocol compliance guidelines in Section 2.  Relay agents and
   proxies MUST NOT reorder AVPs.

   The routing table MAY include a default entry that MUST be used for
   any requests not matching any of the other entries.  The routing
   table MAY consist of only such an entry.

   When a request is routed, the target server MUST have advertised the
   Application Id (see Section 2.4) for the given message or have
   advertised itself as a relay or proxy agent.  Otherwise, an error is
   returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.

2.8.  Role of Diameter Agents

   In addition to clients and servers, the Diameter protocol introduces
   relay, proxy, redirect, and translation agents, each of which is
   defined in Section 1.2.  Diameter agents are useful for several

   o  They can distribute administration of systems to a configurable
      grouping, including the maintenance of security associations.

Top      Up      ToC       Page 29 
   o  They can be used for concentration of requests from a number of
      co-located or distributed NAS equipment sets to a set of like user

   o  They can do value-added processing to the requests or responses.

   o  They can be used for load balancing.

   o  A complex network will have multiple authentication sources, they
      can sort requests and forward towards the correct target.

   The Diameter protocol requires that agents maintain transaction
   state, which is used for failover purposes.  Transaction state
   implies that upon forwarding a request, its Hop-by-Hop Identifier is
   saved; the field is replaced with a locally unique identifier, which
   is restored to its original value when the corresponding answer is
   received.  The request's state is released upon receipt of the
   answer.  A stateless agent is one that only maintains transaction

   The Proxy-Info AVP allows stateless agents to add local state to a
   Diameter request, with the guarantee that the same state will be
   present in the answer.  However, the protocol's failover procedures
   require that agents maintain a copy of pending requests.

   A stateful agent is one that maintains session state information by
   keeping track of all authorized active sessions.  Each authorized
   session is bound to a particular service, and its state is considered
   active until either the agent is notified otherwise or the session
   expires.  Each authorized session has an expiration, which is
   communicated by Diameter servers via the Session-Timeout AVP.

   Maintaining session state may be useful in certain applications, such

   o  Protocol translation (e.g., RADIUS <-> Diameter)

   o  Limiting resources authorized to a particular user

   o  Per-user or per-transaction auditing

   A Diameter agent MAY act in a stateful manner for some requests and
   be stateless for others.  A Diameter implementation MAY act as one
   type of agent for some requests and as another type of agent for

Top      Up      ToC       Page 30 
2.8.1.  Relay Agents

   Relay agents are Diameter agents that accept requests and route
   messages to other Diameter nodes based on information found in the
   messages (e.g., the value of the Destination-Realm AVP Section 6.6).
   This routing decision is performed using a list of supported realms
   and known peers.  This is known as the routing table, as is defined
   further in Section 2.7.

   Relays may, for example, be used to aggregate requests from multiple
   Network Access Servers (NASes) within a common geographical area
   (Point of Presence, POP).  The use of relays is advantageous since it
   eliminates the need for NASes to be configured with the necessary
   security information they would otherwise require to communicate with
   Diameter servers in other realms.  Likewise, this reduces the
   configuration load on Diameter servers that would otherwise be
   necessary when NASes are added, changed, or deleted.

   Relays modify Diameter messages by inserting and removing routing
   information, but they do not modify any other portion of a message.
   Relays SHOULD NOT maintain session state but MUST maintain
   transaction state.

       +------+    --------->     +------+     --------->    +------+
       |      |    1. Request     |      |     2. Request    |      |
       | NAS  |                   | DRL  |                   | HMS  |
       |      |    4. Answer      |      |     3. Answer     |      |
       +------+    <---------     +------+     <---------    +------+            

                  Figure 2: Relaying of Diameter messages

   The example provided in Figure 2 depicts a request issued from a NAS,
   which is an access device, for the user  Prior to
   issuing the request, the NAS performs a Diameter route lookup, using
   "" as the key, and determines that the message is to be
   relayed to a DRL, which is a Diameter relay.  The DRL performs the
   same route lookup as the NAS, and relays the message to the HMS,
   which is's home server.  The HMS identifies that the
   request can be locally supported (via the realm), processes the
   authentication and/or authorization request, and replies with an
   answer, which is routed back to the NAS using saved transaction

   Since relays do not perform any application-level processing, they
   provide relaying services for all Diameter applications; therefore,
   they MUST advertise the Relay Application Id.

Top      Up      ToC       Page 31 
2.8.2.  Proxy Agents

   Similar to relays, proxy agents route Diameter messages using the
   Diameter routing table.  However, they differ since they modify
   messages to implement policy enforcement.  This requires that proxies
   maintain the state of their downstream peers (e.g., access devices)
   to enforce resource usage, provide admission control, and provide

   Proxies may, for example, be used in call control centers or access
   ISPs that provide outsourced connections; they can monitor the number
   and type of ports in use and make allocation and admission decisions
   according to their configuration.

   Since enforcing policies requires an understanding of the service
   being provided, proxies MUST only advertise the Diameter applications
   they support.

2.8.3.  Redirect Agents

   Redirect agents are useful in scenarios where the Diameter routing
   configuration needs to be centralized.  An example is a redirect
   agent that provides services to all members of a consortium, but does
   not wish to be burdened with relaying all messages between realms.
   This scenario is advantageous since it does not require that the
   consortium provide routing updates to its members when changes are
   made to a member's infrastructure.

   Since redirect agents do not relay messages, and only return an
   answer with the information necessary for Diameter agents to
   communicate directly, they do not modify messages.  Since redirect
   agents do not receive answer messages, they cannot maintain session

   The example provided in Figure 3 depicts a request issued from the
   access device, NAS, for the user  The message is
   forwarded by the NAS to its relay, DRL, which does not have a routing
   entry in its Diameter routing table for  The DRL has a
   default route configured to DRD, which is a redirect agent that
   returns a redirect notification to DRL, as well as the HMS' contact
   information.  Upon receipt of the redirect notification, the DRL
   establishes a transport connection with the HMS, if one doesn't
   already exist, and forwards the request to it.

Top      Up      ToC       Page 32 
                                  |      |
                                  | DRD  |
                                  |      |
                                   ^    |
                       2. Request  |    | 3. Redirection
                                   |    |    Notification
                                   |    v
       +------+    --------->     +------+     --------->    +------+
       |      |    1. Request     |      |     4. Request    |      |
       | NAS  |                   | DRL  |                   | HMS  |
       |      |    6. Answer      |      |     5. Answer     |      |
       +------+    <---------     +------+     <---------    +------+           

                 Figure 3: Redirecting a Diameter Message

   Since redirect agents do not perform any application-level
   processing, they provide relaying services for all Diameter
   applications; therefore, they MUST advertise the Relay Application

2.8.4.  Translation Agents

   A translation agent is a device that provides translation between two
   protocols (e.g., RADIUS<->Diameter, TACACS+<->Diameter).  Translation
   agents are likely to be used as aggregation servers to communicate
   with a Diameter infrastructure, while allowing for the embedded
   systems to be migrated at a slower pace.

   Given that the Diameter protocol introduces the concept of long-lived
   authorized sessions, translation agents MUST be session stateful and
   MUST maintain transaction state.

   Translation of messages can only occur if the agent recognizes the
   application of a particular request; therefore, translation agents
   MUST only advertise their locally supported applications.

       +------+    --------->     +------+     --------->    +------+
       |      |  RADIUS Request   |      |  Diameter Request |      |
       | NAS  |                   | TLA  |                   | HMS  |
       |      |  RADIUS Answer    |      |  Diameter Answer  |      |
       +------+    <---------     +------+     <---------    +------+           

                Figure 4: Translation of RADIUS to Diameter

Top      Up      ToC       Page 33 
2.9.  Diameter Path Authorization

   As noted in Section 2.2, Diameter provides transmission-level
   security for each connection using TLS/TCP and DTLS/SCTP.  Therefore,
   each connection can be authenticated and can be replay and integrity

   In addition to authenticating each connection, the entire session
   MUST also be authorized.  Before initiating a connection, a Diameter
   peer MUST check that its peers are authorized to act in their roles.
   For example, a Diameter peer may be authentic, but that does not mean
   that it is authorized to act as a Diameter server advertising a set
   of Diameter applications.

   Prior to bringing up a connection, authorization checks are performed
   at each connection along the path.  Diameter capabilities negotiation
   (CER/CEA) also MUST be carried out, in order to determine what
   Diameter applications are supported by each peer.  Diameter sessions
   MUST be routed only through authorized nodes that have advertised
   support for the Diameter application required by the session.

   As noted in Section 6.1.9, a relay or proxy agent MUST append a
   Route-Record AVP to all requests forwarded.  The AVP contains the
   identity of the peer from which the request was received.

   The home Diameter server, prior to authorizing a session, MUST check
   the Route-Record AVPs to make sure that the route traversed by the
   request is acceptable.  For example, administrators within the home
   realm may not wish to honor requests that have been routed through an
   untrusted realm.  By authorizing a request, the home Diameter server
   is implicitly indicating its willingness to engage in the business
   transaction as specified by any contractual relationship between the
   server and the previous hop.  A DIAMETER_AUTHORIZATION_REJECTED error
   message (see Section 7.1.5) is sent if the route traversed by the
   request is unacceptable.

   A home realm may also wish to check that each accounting request
   message corresponds to a Diameter response authorizing the session.
   Accounting requests without corresponding authorization responses
   SHOULD be subjected to further scrutiny, as should accounting
   requests indicating a difference between the requested and provided

   Forwarding of an authorization response is considered evidence of a
   willingness to take on financial risk relative to the session.  A
   local realm may wish to limit this exposure, for example, by
   establishing credit limits for intermediate realms and refusing to
   accept responses that would violate those limits.  By issuing an

Top      Up      ToC       Page 34 
   accounting request corresponding to the authorization response, the
   local realm implicitly indicates its agreement to provide the service
   indicated in the authorization response.  If the service cannot be
   provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
   message MUST be sent within the accounting request; a Diameter client
   receiving an authorization response for a service that it cannot
   perform MUST NOT substitute an alternate service and then send
   accounting requests for the alternate service instead.

3.  Diameter Header

   A summary of the Diameter header format is shown below.  The 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    |                 Message Length                |
      | Command Flags |                  Command Code                 |
      |                         Application-ID                        |
      |                      Hop-by-Hop Identifier                    |
      |                      End-to-End Identifier                    |
      |  AVPs ...


      This Version field MUST be set to 1 to indicate Diameter Version

    Message Length

      The Message Length field is three octets and indicates the length
      of the Diameter message including the header fields and the padded
      AVPs.  Thus, the Message Length field is always a multiple of 4.

   Command Flags

      The Command Flags field is eight bits.  The following bits are

Top      Up      ToC       Page 35 
          0 1 2 3 4 5 6 7
         |R P E T r r r r|


         If set, the message is a request.  If cleared, the message is
         an answer.


         If set, the message MAY be proxied, relayed, or redirected.  If
         cleared, the message MUST be locally processed.


         If set, the message contains a protocol error, and the message
         will not conform to the CCF described for this command.
         Messages with the 'E' bit set are commonly referred to as error
         messages.  This bit MUST NOT be set in request messages (see
         Section 7.2).

      T(Potentially retransmitted message)

         This flag is set after a link failover procedure, to aid the
         removal of duplicate requests.  It is set when resending
         requests not yet acknowledged, as an indication of a possible
         duplicate due to a link failure.  This bit MUST be cleared when
         sending a request for the first time; otherwise, the sender
         MUST set this flag.  Diameter agents only need to be concerned
         about the number of requests they send based on a single
         received request; retransmissions by other entities need not be
         tracked.  Diameter agents that receive a request with the T
         flag set, MUST keep the T flag set in the forwarded request.
         This flag MUST NOT be set if an error answer message (e.g., a
         protocol error) has been received for the earlier message.  It
         can be set only in cases where no answer has been received from
         the server for a request, and the request has been sent again.
         This flag MUST NOT be set in answer messages.


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

Top      Up      ToC       Page 36 
   Command Code

      The Command Code field is three octets and is used in order to
      communicate the command associated with the message.  The 24-bit
      address space is managed by IANA (see Section 3.1).  Command Code
      values 16,777,214 and 16,777,215 (hexadecimal values FFFFFE-
      FFFFFF) are reserved for experimental use (see Section 11.2).


      Application-ID is four octets and is used to identify for which
      application the message is applicable.  The application can be an
      authentication application, an accounting application, or a
      vendor-specific application.

      The value of the Application-ID field in the header MUST be the
      same as any relevant Application-Id AVPs contained in the message.

   Hop-by-Hop Identifier

      The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in
      network byte order) that aids in matching requests and replies.
      The sender MUST ensure that the Hop-by-Hop Identifier in a request
      is unique on a given connection at any given time, and it MAY
      attempt to ensure that the number is unique across reboots.  The
      sender of an answer message MUST ensure that the Hop-by-Hop
      Identifier field contains the same value that was found in the
      corresponding request.  The Hop-by-Hop Identifier is normally a
      monotonically increasing number, whose start value was randomly
      generated.  An answer message that is received with an unknown
      Hop-by-Hop Identifier MUST be discarded.

   End-to-End Identifier

      The End-to-End Identifier is an unsigned 32-bit integer field (in
      network byte order) that is used to detect duplicate messages.
      Upon reboot, implementations MAY set the high order 12 bits to
      contain the low order 12 bits of current time, and the low order
      20 bits to a random value.  Senders of request messages MUST
      insert a unique identifier on each message.  The identifier MUST
      remain locally unique for a period of at least 4 minutes, even
      across reboots.  The originator of an answer message MUST ensure
      that the End-to-End Identifier field contains the same value that
      was found in the corresponding request.  The End-to-End Identifier
      MUST NOT be modified by Diameter agents of any kind.  The
      combination of the Origin-Host AVP (Section 6.3) and this field is
      used to detect duplicates.  Duplicate requests SHOULD cause the
      same answer to be transmitted (modulo the Hop-by-Hop Identifier

Top      Up      ToC       Page 37 
      field and any routing AVPs that may be present), and they MUST NOT
      affect any state that was set when the original request was
      processed.  Duplicate answer messages that are to be locally
      consumed (see Section 6.2) SHOULD be silently discarded.


      AVPs are a method of encapsulating information relevant to the
      Diameter message.  See Section 4 for more information on AVPs.

3.1.  Command Codes

   Each command Request/Answer pair is assigned a Command Code, and the
   sub-type (i.e., request or answer) is identified via the 'R' bit in
   the Command Flags field of the Diameter header.

   Every Diameter message MUST contain a Command Code in its header's
   Command Code field, which is used to determine the action that is to
   be taken for a particular message.  The following Command Codes are
   defined in the Diameter base protocol:

    Command Name             Abbrev.    Code       Reference
      Abort-Session-Request     ASR       274           8.5.1
      Abort-Session-Answer      ASA       274           8.5.2
      Accounting-Request        ACR       271           9.7.1
      Accounting-Answer         ACA       271           9.7.2
      Capabilities-Exchange-    CER       257           5.3.1
      Capabilities-Exchange-    CEA       257           5.3.2
      Device-Watchdog-Request   DWR       280           5.5.1
      Device-Watchdog-Answer    DWA       280           5.5.2
      Disconnect-Peer-Request   DPR       282           5.4.1
      Disconnect-Peer-Answer    DPA       282           5.4.2
      Re-Auth-Request           RAR       258           8.3.1
      Re-Auth-Answer            RAA       258           8.3.2
      Session-Termination-      STR       275           8.4.1
      Session-Termination-      STA       275           8.4.2

Top      Up      ToC       Page 38 
3.2.  Command Code Format Specification

   Every Command Code defined MUST include a corresponding Command Code
   Format (CCF) specification, which is used to define the AVPs that
   MUST or MAY be present when sending the message.  The following ABNF
   specifies the CCF used in the definition:

   command-def      = "<" command-name ">" "::=" diameter-message

   command-name     = diameter-name

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

   diameter-message = header   *fixed  *required *optional

   header           = "<Diameter-Header:" command-id
                         [r-bit] [p-bit] [e-bit] [application-id]">"

   application-id   = 1*DIGIT

   command-id       = 1*DIGIT
                      ; The Command Code assigned to the command.

   r-bit            = ", REQ"
                      ; If present, the 'R' bit in the Command
                      ; Flags is set, indicating that the message
                      ; is a request as opposed to an answer.

   p-bit            = ", PXY"
                      ; If present, the 'P' bit in the Command
                      ; Flags is set, indicating that the message
                      ; is proxiable.

   e-bit            = ", ERR"
                      ; If present, the 'E' bit in the Command
                      ; Flags is set, indicating that the answer
                      ; message contains a Result-Code AVP in
                      ; the "protocol error" class.

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

   required         = [qual] "{" avp-spec "}"
                      ; The AVP MUST be present and can appear
                      ; anywhere in the message.

Top      Up      ToC       Page 39 
   optional         = [qual] "[" avp-name "]"
                      ; The avp-name in the 'optional' rule cannot
                      ; evaluate to any AVP Name that is included
                      ; in a fixed or required rule.  The AVP can
                      ; appear anywhere in the message.
                      ; NOTE:  "[" and "]" have a slightly different
                      ; meaning than in ABNF.  These braces
                      ; cannot be used to express optional fixed rules
                      ; (such as an optional ICV at the end).  To do
                      ; this, the convention is '0*1fixed'.

   qual             = [min] "*" [max]
                      ; See ABNF conventions, RFC 5234, Section 4.
                      ; The absence of any qualifier 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 AVP may be
                      ; present.  If an optional rule has a qualifier,
                      ; then the value of min MUST be 0 if present.

   min              = 1*DIGIT
                      ; The minimum number of times the element may
                      ; be present.  If absent, the default value is 0
                      ; for fixed and optional rules and 1 for
                      ; required rules.  The value MUST be at least 1
                      ; for required rules.

   max              = 1*DIGIT
                      ; The maximum number of times the element may
                      ; be present.  If absent, the default value is
                      ; infinity.  A value of 0 implies the AVP MUST
                      ; NOT be present.

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

   avp-name         = avp-spec / "AVP"
                      ; The string "AVP" stands for *any* arbitrary AVP
                      ; Name, not otherwise listed in that Command Code
                      ; definition.  The inclusion of this string
                      ; is recommended for all CCFs to allow for
                      ; extensibility.

Top      Up      ToC       Page 40 
   The following is a definition of a fictitious Command Code:

   Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
                       { User-Name }
                    1* { Origin-Host }
                     * [ AVP ]

3.3.  Diameter Command Naming Conventions

   Diameter command names typically includes one or more English words
   followed by the verb "Request" or "Answer".  Each English word is
   delimited by a hyphen.  A three-letter acronym for both the request
   and answer is also normally provided.

   An example is a message set used to terminate a session.  The command
   name is Session-Terminate-Request and Session-Terminate-Answer, while
   the acronyms are STR and STA, respectively.

   Both the request and the answer for a given command share the same
   Command Code.  The request is identified by the R(equest) bit in the
   Diameter header set to one (1), to ask that a particular action be
   performed, such as authorizing a user or terminating a session.  Once
   the receiver has completed the request, it issues the corresponding
   answer, which includes a result code that communicates one of the

   o  The request was successful

   o  The request failed

   o  An additional request has to be sent to provide information the
      peer requires prior to returning a successful or failed answer.

   o  The receiver could not process the request, but provides
      information about a Diameter peer that is able to satisfy the
      request, known as redirect.

   Additional information, encoded within AVPs, may also be included in
   answer messages.

4.  Diameter AVPs

   Diameter AVPs carry specific authentication, accounting,
   authorization, and routing information as well as configuration
   details for the request and reply.

Top      Up      ToC       Page 41 
   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 until a word
   boundary is reached.  The length of the padding is not reflected in
   the AVP Length field.

4.1.  AVP Header

   The fields in the AVP header MUST be sent in network byte order.  The
   format of the 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                            |
      |V M P r r r r r|                  AVP Length                   |
      |                        Vendor-ID (opt)                        |
      |    Data ...

   AVP Code

      The AVP Code, combined with the Vendor-Id field, identifies the
      attribute uniquely.  AVP numbers 1 through 255 are reserved for
      reuse of RADIUS attributes, without setting the Vendor-Id field.
      AVP numbers 256 and above are used for Diameter, which are
      allocated by IANA (see Section 11.1.1).

   AVP Flags

      The AVP Flags field informs the receiver how each attribute must
      be handled.  New Diameter applications SHOULD NOT define
      additional AVP Flag bits.  However, note that new Diameter
      applications MAY define additional bits within the AVP header, and
      an unrecognized bit SHOULD be considered an error.  The sender of
      the AVP MUST set 'R' (reserved) bits to 0 and the receiver SHOULD
      ignore all 'R' (reserved) bits.  The 'P' bit has been reserved for
      future usage of end-to-end security.  At the time of writing,
      there are no end-to-end security mechanisms specified; therefore,
      the 'P' bit SHOULD be set to 0.

      The 'M' bit, known as the Mandatory bit, indicates whether the
      receiver of the AVP MUST parse and understand the semantics of the
      AVP including its content.  The receiving entity MUST return an
      appropriate error message if it receives an AVP that has the M-bit

Top      Up      ToC       Page 42 
      set but does not understand it.  An exception applies when the AVP
      is embedded within a Grouped AVP.  See Section 4.4 for details.
      Diameter relay and redirect agents MUST NOT reject messages with
      unrecognized AVPs.

      The 'M' bit MUST be set according to the rules defined in the
      application specification that introduces or reuses this AVP.
      Within a given application, the M-bit setting for an AVP is
      defined either for all command types or for each command type.

      AVPs with the 'M' bit cleared are informational only; a receiver
      that receives a message with such an AVP that is not supported, or
      whose value is not supported, MAY simply ignore the AVP.

      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

   AVP Length

      The AVP Length field is three octets, and indicates the number of
      octets in this AVP including the AVP Code field, AVP Length field,
      AVP Flags field, Vendor-ID field (if present), and the AVP Data
      field.  If a message is received with an invalid attribute length,
      the message MUST be rejected.

4.1.1.  Optional Header Elements

   The AVP header contains one optional field.  This field is only
   present if the respective bit-flag is enabled.


      The Vendor-ID field is present if the 'V' bit is set in the AVP
      Flags field.  The optional four-octet Vendor-ID field contains the
      IANA-assigned "SMI Network Management Private Enterprise Codes"
      [ENTERPRISE] value, encoded in network byte order.  Any vendors or
      standardization organizations that are also treated like vendors
      in the IANA-managed "SMI Network Management Private Enterprise
      Codes" space wishing to implement a vendor-specific Diameter AVP
      MUST 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) or with future IETF

Top      Up      ToC       Page 43 
      A Vendor-ID value of zero (0) corresponds to the IETF-adopted AVP
      values, as managed by IANA.  Since the absence of the Vendor-ID
      field implies that the AVP in question is not vendor specific,
      implementations MUST NOT use the value of zero (0) for the
      Vendor-ID field.

4.2.  Basic AVP Data Formats

   The Data field is zero or more octets and contains information
   specific to the Attribute.  The format and length of the Data field
   is determined by the AVP Code and AVP Length fields.  The format of
   the Data field MUST be one of the following base data types or a data
   type derived from the base data types.  In the event that a new Basic
   AVP Data Format is needed, a new version of this RFC MUST be created.


      The data contains arbitrary data of variable length.  Unless
      otherwise noted, the AVP Length field MUST be set to at least 8
      (12 if the 'V' bit is enabled).  AVP values of this type that are
      not a multiple of 4 octets in length are followed by the necessary
      padding so that the next AVP (if any) will start on a 32-bit


      32-bit signed value, in network byte order.  The AVP Length field
      MUST be set to 12 (16 if the 'V' bit is enabled).


      64-bit signed value, in network byte order.  The AVP Length field
      MUST be set to 16 (20 if the 'V' bit is enabled).


      32-bit unsigned value, in network byte order.  The AVP Length
      field MUST be set to 12 (16 if the 'V' bit is enabled).


      64-bit unsigned value, in network byte order.  The AVP Length
      field MUST be set to 16 (20 if the 'V' bit is enabled).

Top      Up      ToC       Page 44 

      This represents floating point values of single precision as
      described by [FLOATPOINT].  The 32-bit value is transmitted in
      network byte order.  The AVP Length field MUST be set to 12 (16 if
      the 'V' bit is enabled).


      This represents floating point values of double precision as
      described by [FLOATPOINT].  The 64-bit value is transmitted in
      network byte order.  The AVP Length field MUST be set to 16 (20 if
      the 'V' bit is enabled).


      The Data field is specified as a sequence of AVPs.  These AVPs are
      concatenated -- including their headers and padding -- in the
      order in which they are specified and the result encapsulated in
      the Data field.  The AVP Length field is set to 8 (12 if the 'V'
      bit is enabled) plus the total length of all included AVPs,
      including their headers and padding.  Thus, the AVP Length field
      of an AVP of type Grouped is always a multiple of 4.

4.3.  Derived AVP Data Formats

   In addition to using the Basic AVP Data Formats, applications may
   define data formats derived from the Basic AVP Data Formats.  An
   application that defines new Derived AVP Data Formats MUST include
   them in a section titled "Derived AVP Data Formats", using the same
   format as the definitions below.  Each new definition MUST be either
   defined or listed with a reference to the RFC that defines the

4.3.1.  Common Derived AVP Data Formats

   The following are commonly used Derived AVP Data Formats.


      The Address format is derived from the OctetString Basic AVP
      Format.  It is a discriminated union representing, for example, a
      32-bit (IPv4) [RFC0791] or 128-bit (IPv6) [RFC4291] address, most
      significant octet first.  The first two octets of the Address AVP
      represent the AddressType, which contains an Address Family,
      defined in [IANAADFAM].  The AddressType is used to discriminate
      the content and format of the remaining octets.

Top      Up      ToC       Page 45 

      The Time format is derived from the OctetString Basic AVP Format.
      The string MUST contain four octets, in the same format as the
      first four bytes are in the NTP timestamp format.  The NTP
      timestamp format is defined in Section 3 of [RFC5905].

      This represents the number of seconds since 0h on 1 January 1900
      with respect to the Coordinated Universal Time (UTC).

      On 6h 28m 16s UTC, 7 February 2036, the time value will overflow.
      Simple Network Time Protocol (SNTP) [RFC5905] describes a
      procedure to extend the time to 2104.  This procedure MUST be
      supported by all Diameter nodes.


      The UTF8String format is derived from the OctetString Basic AVP
      Format.  This is a human-readable string represented using the
      ISO/IEC IS 10646-1 character set, encoded as an OctetString using
      the UTF-8 transformation format [RFC3629].

      Since additional code points are added by amendments to the 10646
      standard from time to time, implementations MUST be prepared to
      encounter any code point from 0x00000001 to 0x7fffffff.  Byte
      sequences that do not correspond to the valid encoding of a code
      point into UTF-8 charset or are outside this range are prohibited.

      The use of control codes SHOULD be avoided.  When it is necessary
      to represent a new line, the control code sequence CR LF SHOULD be

      The use of leading or trailing white space SHOULD be avoided.

      For code points not directly supported by user interface hardware
      or software, an alternative means of entry and display, such as
      hexadecimal, MAY be provided.

      For information encoded in 7-bit US-ASCII, the UTF-8 charset is
      identical to the US-ASCII charset.

      UTF-8 may require multiple bytes to represent a single character /
      code point; thus, the length of a UTF8String in octets may be
      different from the number of characters encoded.

      Note that the AVP Length field of an UTF8String is measured in
      octets not characters.

Top      Up      ToC       Page 46 

      The DiameterIdentity format is derived from the OctetString Basic
      AVP Format.

                        DiameterIdentity  = FQDN/Realm

   The DiameterIdentity value is used to uniquely identify either:

      *  A Diameter node for purposes of duplicate connection and
         routing loop detection.

      *  A Realm to determine whether messages can be satisfied locally
         or whether they must be routed or redirected.

      When a DiameterIdentity value is used to identify a Diameter node,
      the contents of the string MUST be the Fully Qualified Domain Name
      (FQDN) of the Diameter node.  If multiple Diameter nodes run on
      the same host, each Diameter node MUST be assigned a unique
      DiameterIdentity.  If a Diameter node can be identified by several
      FQDNs, a single FQDN should be picked at startup and used as the
      only DiameterIdentity for that node, whatever the connection on
      which it is sent.  In this document, note that DiameterIdentity is
      in ASCII form in order to be compatible with existing DNS
      infrastructure.  See Appendix D for interactions between the
      Diameter protocol and Internationalized Domain Names (IDNs).


      The DiameterURI MUST follow the Uniform Resource Identifiers (RFC
      3986) syntax [RFC3986] rules specified below:

      "aaa://" FQDN [ port ] [ transport ] [ protocol ]

                      ; No transport security

      "aaas://" FQDN [ port ] [ transport ] [ protocol ]

                      ; Transport security used

      FQDN               = < Fully Qualified Domain Name >

Top      Up      ToC       Page 47 
      port               = ":" 1*DIGIT

                      ; One of the ports used to listen for
                      ; incoming connections.
                      ; If absent, the default Diameter port
                      ; (3868) is assumed if no transport
                      ; security is used and port 5658 when
                      ; transport security (TLS/TCP and DTLS/SCTP)
                      ; is used.

      transport          = ";transport=" transport-protocol

                      ; One of the transports used to listen
                      ; for incoming connections.  If absent,
                      ; the default protocol is assumed to be TCP.
                      ; UDP MUST NOT be used when the aaa-protocol
                      ; field is set to diameter.

      transport-protocol = ( "tcp" / "sctp" / "udp" )

      protocol           = ";protocol=" aaa-protocol

                      ; If absent, the default AAA protocol
                      ; is Diameter.

      aaa-protocol       = ( "diameter" / "radius" / "tacacs+" )

      The following are examples of valid Diameter host identities:



      The Enumerated format is derived from the Integer32 Basic AVP
      Format.  The definition contains a list of valid values and their
      interpretation and is described in the Diameter application
      introducing the AVP.

Top      Up      ToC       Page 48 

      The IPFilterRule format is derived from the OctetString Basic AVP
      Format and uses the ASCII charset.  The rule syntax is a modified
      subset of ipfw(8) from FreeBSD.  Packets may be filtered based on
      the following information that is associated with it:

            Direction                          (in or out)
            Source and destination IP address  (possibly masked)
            Source and destination port        (lists or ranges)
            TCP flags
            IP fragment flag
            IP options
            ICMP types

   Rules for the appropriate direction are evaluated in order, with the
   first matched rule terminating the evaluation.  Each packet is
   evaluated once.  If no rule matches, the packet is dropped if the
   last rule evaluated was a permit, and passed if the last rule was a

   IPFilterRule filters MUST follow the format:

         action dir proto from src to dst [options]

         action       permit - Allow packets that match the rule.
                      deny   - Drop packets that match the rule.

         dir          "in" is from the terminal, "out" is to the

         proto        An IP protocol specified by number.  The "ip"
                      keyword means any protocol will match.

         src and dst  <address/mask> [ports]

                      The <address/mask> may be specified as:
                      ipno       An IPv4 or IPv6 number in dotted-
                                 quad or canonical IPv6 form.  Only
                                 this exact IP number will match the

Top      Up      ToC       Page 49 
                      ipno/bits  An IP number as above with a mask
                                 width of the form  In
                                 this case, all IP numbers from
                        to will match.
                                 The bit width MUST be valid for the
                                 IP version, and the IP number MUST
                                 NOT have bits set beyond the mask.
                                 For a match to occur, the same IP
                                 version must be present in the
                                 packet that was used in describing
                                 the IP address.  To test for a
                                 particular IP version, the bits part
                                 can be set to zero.  The keyword
                                 "any" is or the IPv6
                                 equivalent.  The keyword "assigned"
                                 is the address or set of addresses
                                 assigned to the terminal.  For IPv4,
                                 a typical first rule is often "deny
                                 in ip! assigned".

                      The sense of the match can be inverted by
                      preceding an address with the not modifier (!),
                      causing all other addresses to be matched
                      instead.  This does not affect the selection of
                      port numbers.

                      With the TCP, UDP, and SCTP protocols, optional
                      ports may be specified as:


                       The '-' notation specifies a range of ports
                      (including boundaries).

                      Fragmented packets that have a non-zero offset
                      (i.e., not the first fragment) will never match
                      a rule that has one or more port
                      specifications.  See the frag option for
                      details on matching fragmented packets.

            frag    Match if the packet is a fragment and this is not
                    the first fragment of the datagram.  frag may not
                    be used in conjunction with either tcpflags or
                    TCP/UDP port specifications.

Top      Up      ToC       Page 50 
            ipoptions spec
                    Match if the IP header contains the comma-separated
                    list of options specified in spec.  The
                    supported IP options are:

                    ssrr (strict source route), lsrr (loose source
                    route), rr (record packet route), and ts
                    (timestamp).  The absence of a particular option
                    may be denoted with a '!'.

            tcpoptions spec
                    Match if the TCP header contains the comma-separated
                    list of options specified in spec.  The
                    supported TCP options are:

                    mss (maximum segment size), window (tcp window
                    advertisement), sack (selective ack), ts (rfc1323
                    timestamp), and cc (rfc1644 t/tcp connection
                    count).  The absence of a particular option may
                    be denoted with a '!'.

                    TCP packets only.  Match packets that have the RST
                    or ACK bits set.

            setup   TCP packets only.  Match packets that have the SYN
                    bit set but no ACK bit.

            tcpflags spec
                    TCP packets only.  Match if the TCP header
                    contains the comma-separated list of flags
                    specified in spec.  The supported TCP flags are:

                    fin, syn, rst, psh, ack, and urg.  The absence of a
                    particular flag may be denoted with a '!'.  A rule
                    that contains a tcpflags specification can never
                    match a fragmented packet that has a non-zero
                    offset.  See the frag option for details on
                    matching fragmented packets.

            icmptypes types
                    ICMP packets only.  Match if the ICMP type is in
                    the list types.  The list may be specified as any
                    combination of ranges or individual types
                    separated by commas.  Both the numeric values and
                    the symbolic values listed below can be used.  The
                    supported ICMP types are:

Top      Up      ToC       Page 51 
                    echo reply (0), destination unreachable (3),
                    source quench (4), redirect (5), echo request
                    (8), router advertisement (9), router
                    solicitation (10), time-to-live exceeded (11), IP
                    header bad (12), timestamp request (13),
                    timestamp reply (14), information request (15),
                    information reply (16), address mask request (17),
                    and address mask reply (18).

   There is one kind of packet that the access device MUST always
   discard, that is an IP fragment with a fragment offset of one.  This
   is a valid packet, but it only has one use, to try to circumvent

   An access device that is unable to interpret or apply a deny rule
   MUST terminate the session.  An access device that is unable to
   interpret or apply a permit rule MAY apply a more restrictive rule.
   An access device MAY apply deny rules of its own before the supplied
   rules, for example to protect the access device owner's

4.4.   Grouped AVP Values

   The Diameter protocol allows AVP values of type 'Grouped'.  This
   implies that the Data field is actually a sequence of AVPs.  It is
   possible to include an AVP with a Grouped type within a Grouped type,
   that is, to nest them.  AVPs within an AVP of type Grouped have the
   same padding requirements as non-Grouped AVPs, as defined in
   Section 4.4.

   The AVP Code numbering space of all AVPs included in a Grouped AVP is
   the same as for non-Grouped AVPs.  Receivers of a Grouped AVP that
   does not have the 'M' (mandatory) bit set and one or more of the
   encapsulated AVPs within the group has the 'M' (mandatory) bit set
   MAY simply be ignored if the Grouped AVP itself is unrecognized.  The
   rule applies even if the encapsulated AVP with its 'M' (mandatory)
   bit set is further encapsulated within other sub-groups, i.e., other
   Grouped AVPs embedded within the Grouped AVP.

   Every Grouped AVP definition MUST include a corresponding grammar,
   using ABNF [RFC5234] (with modifications), as defined below.

         grouped-avp-def  = "<" name ">" "::=" avp

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

Top      Up      ToC       Page 52 
         name             = name-fmt
                            ; The name has to be the name of an AVP,
                            ; defined in the base or extended Diameter
                            ; specifications.

         avp              = header *fixed *required *optional

         header           = "<" "AVP-Header:" avpcode [vendor] ">"

         avpcode          = 1*DIGIT
                            ; The AVP Code assigned to the Grouped AVP.

         vendor           = 1*DIGIT
                            ; The Vendor-ID assigned to the Grouped AVP.
                            ; If absent, the default value of zero is
                            ; used.

4.4.1.  Example AVP with a Grouped Data Type

   The Example-AVP (AVP Code 999999) is of type Grouped and is used to
   clarify how Grouped AVP values work.  The Grouped Data field has the
   following CCF grammar:

         Example-AVP  ::= < AVP Header: 999999 >
                          { Origin-Host }
                        1*{ Session-Id }
                         *[ AVP ]

      An Example-AVP with Grouped Data follows.

      The Origin-Host AVP (Section 6.3) is required.  In this case:

         Origin-Host = "".

      One or more Session-Ids must follow.  Here there are two:

         Session-Id =

         Session-Id =

Top      Up      ToC       Page 53 
      optional AVPs included are

         Recovery-Policy = <binary>

         Futuristic-Acct-Record = <binary>

   The data for the optional AVPs is represented in hexadecimal form
   since the format of these AVPs is not known at the time of definition
   of the Example-AVP group nor (likely) at the time when the example
   instance of this AVP is interpreted -- except by Diameter
   implementations that support the same set of AVPs.  The encoding
   example illustrates how padding is used and how length fields are
   calculated.  Also, note that AVPs may be present in the Grouped AVP
   value that the receiver cannot interpret (here, the Recover-Policy
   and Futuristic-Acct-Record AVPs).  The length of the Example-AVP is
   the sum of all the length of the member AVPs, including their
   padding, plus the Example-AVP header size.

Top      Up      ToC       Page 54 
   This AVP would be encoded as follows:

         0       1       2       3       4       5       6       7
   0  |     Example AVP Header (AVP Code = 999999), Length = 496      |
   8  |     Origin-Host AVP Header (AVP Code = 264), Length = 19      |
   16 |  'e'  |  'x'  |  'a'  |  'm'  |  'p'  |  'l'  |  'e'  |  '.'  |
   24 |  'c'  |  'o'  |  'm'  |Padding|     Session-Id AVP Header     |
   32 | (AVP Code = 263), Length = 49 |  'g'  |  'r'  |  'u'  |  'm'  |
                                    . . .
   72 |  'F'  |  '3'  |  'B'  |  '8'  |  '1'  |Padding|Padding|Padding|
   80 |     Session-Id AVP Header (AVP Code = 263), Length = 50       |
   88 |  'g'  |  'r'  |  'u'  |  'm'  |  'p'  |  '.'  |  'e'  |  'x'  |
                                   . . .
   120|  '5'  |  '8'  |  ';'  |  '0'  |  'A'  |  'F'  |  '3'  |  'B'  |
   128|  '8'  |  '2'  |Padding|Padding|  Recovery-Policy Header (AVP  |
   136|  Code = 8341), Length = 223   | 0x21  | 0x63  | 0xbc  | 0x1d  |
   144|  0x0a | 0xd8  | 0x23  | 0x71  | 0xf6  | 0xbc  | 0x09  | 0x48  |
                                    . . .
   352|  0x8c | 0x7f  | 0x92  |Padding| Futuristic-Acct-Record Header |
   328|(AVP Code = 15930),Length = 137| 0xfe  | 0x19  | 0xda  | 0x58  |
   336|  0x02 | 0xac  | 0xd9  | 0x8b  | 0x07  | 0xa5  | 0xb8  | 0xc6  |
                                    . . .
   488|  0xe4 | 0x99  | 0x68  | 0xf8  | 0x41  |Padding|Padding|Padding|

Top      Up      ToC       Page 55 
4.5.  Diameter Base Protocol AVPs

   The following table describes the Diameter AVPs defined in the base
   protocol, their AVP Code values, types, and possible flag values.

   Due to space constraints, the short form DiamIdent is used to
   represent DiameterIdentity.

Top      Up      ToC       Page 56 
                                            | AVP Flag |
                                            |  rules   |
                   AVP  Section             |    |MUST |
   Attribute Name  Code Defined  Data Type  |MUST| NOT |
   Acct-             85  9.8.2   Unsigned32 | M  |  V  |
     Interim-Interval                       |    |     |
   Accounting-      483  9.8.7   Enumerated | M  |  V  |
     Realtime-Required                      |    |     |
   Acct-            50   9.8.5   UTF8String | M  |  V  |
     Multi-Session-Id                       |    |     |
   Accounting-      485  9.8.3   Unsigned32 | M  |  V  |
     Record-Number                          |    |     |
   Accounting-      480  9.8.1   Enumerated | M  |  V  |
     Record-Type                            |    |     |
   Acct-             44  9.8.4   OctetString| M  |  V  |
    Session-Id                              |    |     |
   Accounting-      287  9.8.6   Unsigned64 | M  |  V  |
     Sub-Session-Id                         |    |     |
   Acct-            259  6.9     Unsigned32 | M  |  V  |
     Application-Id                         |    |     |
   Auth-            258  6.8     Unsigned32 | M  |  V  |
     Application-Id                         |    |     |
   Auth-Request-    274  8.7     Enumerated | M  |  V  |
      Type                                  |    |     |
   Authorization-   291  8.9     Unsigned32 | M  |  V  |
     Lifetime                               |    |     |
   Auth-Grace-      276  8.10    Unsigned32 | M  |  V  |
     Period                                 |    |     |
   Auth-Session-    277  8.11    Enumerated | M  |  V  |
     State                                  |    |     |
   Re-Auth-Request- 285  8.12    Enumerated | M  |  V  |
     Type                                   |    |     |
   Class             25  8.20    OctetString| M  |  V  |
   Destination-Host 293  6.5     DiamIdent  | M  |  V  |
   Destination-     283  6.6     DiamIdent  | M  |  V  |
     Realm                                  |    |     |
   Disconnect-Cause 273  5.4.3   Enumerated | M  |  V  |
   Error-Message    281  7.3     UTF8String |    | V,M |
   Error-Reporting- 294  7.4     DiamIdent  |    | V,M |
     Host                                   |    |     |
   Event-Timestamp   55  8.21    Time       | M  |  V  |
   Experimental-    297  7.6     Grouped    | M  |  V  |
      Result                                |    |     |

Top      Up      ToC       Page 57 
                                            | AVP Flag |
                                            |  rules   |
                   AVP  Section             |    |MUST |
   Attribute Name  Code Defined  Data Type  |MUST| NOT |
   Experimental-    298  7.7     Unsigned32 | M  |  V  |
      Result-Code                           |    |     |
   Failed-AVP       279  7.5     Grouped    | M  |  V  |
   Firmware-        267  5.3.4   Unsigned32 |    | V,M |
     Revision                               |    |     |
   Host-IP-Address  257  5.3.5   Address    | M  |  V  |
   Inband-Security                          | M  |  V  |
      -Id           299  6.10    Unsigned32 |    |     |
   Multi-Round-     272  8.19    Unsigned32 | M  |  V  |
     Time-Out                               |    |     |
   Origin-Host      264  6.3     DiamIdent  | M  |  V  |
   Origin-Realm     296  6.4     DiamIdent  | M  |  V  |
   Origin-State-Id  278  8.16    Unsigned32 | M  |  V  |
   Product-Name     269  5.3.7   UTF8String |    | V,M |
   Proxy-Host       280  6.7.3   DiamIdent  | M  |  V  |
   Proxy-Info       284  6.7.2   Grouped    | M  |  V  |
   Proxy-State       33  6.7.4   OctetString| M  |  V  |
   Redirect-Host    292  6.12    DiamURI    | M  |  V  |
   Redirect-Host-   261  6.13    Enumerated | M  |  V  |
      Usage                                 |    |     |
   Redirect-Max-    262  6.14    Unsigned32 | M  |  V  |
      Cache-Time                            |    |     |
   Result-Code      268  7.1     Unsigned32 | M  |  V  |
   Route-Record     282  6.7.1   DiamIdent  | M  |  V  |
   Session-Id       263  8.8     UTF8String | M  |  V  |
   Session-Timeout   27  8.13    Unsigned32 | M  |  V  |
   Session-Binding  270  8.17    Unsigned32 | M  |  V  |
   Session-Server-  271  8.18    Enumerated | M  |  V  |
     Failover                               |    |     |
   Supported-       265  5.3.6   Unsigned32 | M  |  V  |
     Vendor-Id                              |    |     |
   Termination-     295  8.15    Enumerated | M  |  V  |
      Cause                                 |    |     |
   User-Name          1  8.14    UTF8String | M  |  V  |
   Vendor-Id        266  5.3.3   Unsigned32 | M  |  V  |
   Vendor-Specific- 260  6.11    Grouped    | M  |  V  |
      Application-Id                        |    |     |

Next RFC Part