in Index   Prev   Next

RFC 6733

Diameter Base Protocol

Pages: 152
Proposed Standard
Obsoletes:  35885719
Updated by:  70758553
Part 2 of 5 – Pages 20 to 57
First   Prev   Next

Top   ToC   RFC6733 - Page 20   prevText

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   ToC   RFC6733 - 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   ToC   RFC6733 - 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 discovery.
Top   ToC   RFC6733 - 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 sessions. 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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. StatusT 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 certificates. 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, certificates).
Top   ToC   RFC6733 - 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 guidelines. 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   ToC   RFC6733 - 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 reasons: o They can distribute administration of systems to a configurable grouping, including the maintenance of security associations.
Top   ToC   RFC6733 - 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   ToC   RFC6733 - 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 state. 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   ToC   RFC6733 - 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 provisioning. 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 state. 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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 protected. 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 service. 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   ToC   RFC6733 - 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+- Version This Version field MUST be set to 1 to indicate Diameter Version 1. 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 assigned:
Top   ToC   RFC6733 - 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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: Section 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 Request Capabilities-Exchange- CEA 257 5.3.2 Answer 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 Request Session-Termination- STA 275 8.4.2 Answer
Top   ToC   RFC6733 - 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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 following: 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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. Vendor-ID 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 AVPs.
Top   ToC   RFC6733 - 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. OctetString 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 boundary. Integer32 32-bit signed value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). Integer64 64-bit signed value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled). Unsigned32 32-bit unsigned value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). Unsigned64 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   ToC   RFC6733 - 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 format.

4.3.1. Common Derived AVP Data Formats

The following are commonly used Derived AVP Data Formats. Address 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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 = ";23432;893;0AF3B81" Session-Id = ";23561;2358;0AF3B82"
Top   ToC   RFC6733 - 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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   ToC   RFC6733 - 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 page on part 3)

Next Section