Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6733

Diameter Base Protocol

Pages: 152
Proposed Standard
Errata
Obsoletes:  35885719
Updated by:  70758553
Part 5 of 5 – Pages 123 to 152
First   Prev   None

Top   ToC   RFC6733 - Page 123   prevText

9. Accounting

This accounting protocol is based on a server directed model with capabilities for real-time delivery of accounting information. Several fault resilience methods [RFC2975] have been built into the protocol in order minimize loss of accounting data in various fault situations and under different assumptions about the capabilities of the used devices.

9.1. Server Directed Model

The server directed model means that the device generating the accounting data gets information from either the authorization server (if contacted) or the accounting server regarding the way accounting data shall be forwarded. This information includes accounting record timeliness requirements. As discussed in [RFC2975], real-time transfer of accounting records is a requirement, such as the need to perform credit-limit checks and fraud detection. Note that batch accounting is not a requirement, and is therefore not supported by Diameter. Should batched accounting be required in the future, a new Diameter application will need to be created, or it could be handled using another protocol. Note, however, that even if at the Diameter layer, accounting requests are processed one by one; transport protocols used under Diameter typically batch several requests in the same packet under heavy traffic conditions. This may be sufficient for many applications. The authorization server (chain) directs the selection of proper transfer strategy, based on its knowledge of the user and relationships of roaming partnerships. The server (or agents) uses the Acct-Interim-Interval and Accounting-Realtime-Required AVPs to control the operation of the Diameter peer operating as a client. The Acct-Interim-Interval AVP, when present, instructs the Diameter node acting as a client to produce accounting records continuously even during a session. Accounting-Realtime-Required AVP is used to control the behavior of the client when the transfer of accounting records from the Diameter client is delayed or unsuccessful. The Diameter accounting server MAY override the interim interval or the real-time requirements by including the Acct-Interim-Interval or Accounting-Realtime-Required AVP in the Accounting-Answer message. When one of these AVPs is present, the latest value received SHOULD be used in further accounting activities for the same session.
Top   ToC   RFC6733 - Page 124

9.2. Protocol Messages

A Diameter node that receives a successful authentication and/or authorization message from the Diameter server SHOULD collect accounting information for the session. The Accounting-Request message is used to transmit the accounting information to the Diameter server, which MUST reply with the Accounting-Answer message to confirm reception. The Accounting-Answer message includes the Result-Code AVP, which MAY indicate that an error was present in the accounting message. The value of the Accounting-Realtime-Required AVP received earlier for the session in question may indicate that the user's session has to be terminated when a rejected Accounting- Request message was received.

9.3. Accounting Application Extension and Requirements

Each Diameter application (e.g., NASREQ, Mobile IP) SHOULD define its service-specific AVPs that MUST be present in the Accounting-Request message in a section titled "Accounting AVPs". The application MUST assume that the AVPs described in this document will be present in all Accounting messages, so only their respective service-specific AVPs need to be defined in that section. Applications have the option of using one or both of the following accounting application extension models: Split Accounting Service The accounting message will carry the Application Id of the Diameter base accounting application (see Section 2.4). Accounting messages may be routed to Diameter nodes other than the corresponding Diameter application. These nodes might be centralized accounting servers that provide accounting service for multiple different Diameter applications. These nodes MUST advertise the Diameter base accounting Application Id during capabilities exchange. Coupled Accounting Service The accounting message will carry the Application Id of the application that is using it. The application itself will process the received accounting records or forward them to an accounting server. There is no accounting application advertisement required during capabilities exchange, and the accounting messages will be routed the same way as any of the other application messages. In cases where an application does not define its own accounting service, it is preferred that the split accounting model be used.
Top   ToC   RFC6733 - Page 125

9.4. Fault Resilience

Diameter base protocol mechanisms are used to overcome small message loss and network faults of a temporary nature. Diameter peers acting as clients MUST implement the use of failover to guard against server failures and certain network failures. Diameter peers acting as agents or related off-line processing systems MUST detect duplicate accounting records caused by the sending of the same record to several servers and duplication of messages in transit. This detection MUST be based on the inspection of the Session-Id and Accounting-Record-Number AVP pairs. Appendix C discusses duplicate detection needs and implementation issues. Diameter clients MAY have non-volatile memory for the safe storage of accounting records over reboots or extended network failures, network partitions, and server failures. If such memory is available, the client SHOULD store new accounting records there as soon as the records are created and until a positive acknowledgement of their reception from the Diameter server has been received. Upon a reboot, the client MUST start sending the records in the non-volatile memory to the accounting server with the appropriate modifications in termination cause, session length, and other relevant information in the records. A further application of this protocol may include AVPs to control the maximum number of accounting records that may be stored in the Diameter client without committing them to the non-volatile memory or transferring them to the Diameter server. The client SHOULD NOT remove the accounting data from any of its memory areas before the correct Accounting-Answer has been received. The client MAY remove the oldest, undelivered, or as yet unacknowledged accounting data if it runs out of resources such as memory. It is an implementation-dependent matter for the client to accept new sessions under this condition.

9.5. Accounting Records

In all accounting records, the Session-Id AVP MUST be present; the User-Name AVP MUST be present if it is available to the Diameter client. Different types of accounting records are sent depending on the actual type of accounted service and the authorization server's directions for interim accounting. If the accounted service is a
Top   ToC   RFC6733 - Page 126
   one-time event, meaning that the start and stop of the event are
   simultaneous, then the Accounting-Record-Type AVP MUST be present and
   set to the value EVENT_RECORD.

   If the accounted service is of a measurable length, then the AVP MUST
   use the values START_RECORD, STOP_RECORD, and possibly,
   INTERIM_RECORD.  If the authorization server has not directed interim
   accounting to be enabled for the session, two accounting records MUST
   be generated for each service of type session.  When the initial
   Accounting-Request for a given session is sent, the Accounting-
   Record-Type AVP MUST be set to the value START_RECORD.  When the last
   Accounting-Request is sent, the value MUST be STOP_RECORD.

   If the authorization server has directed interim accounting to be
   enabled, the Diameter client MUST produce additional records between
   the START_RECORD and STOP_RECORD, marked INTERIM_RECORD.  The
   production of these records is directed by Acct-Interim-Interval as
   well as any re-authentication or re-authorization of the session.
   The Diameter client MUST overwrite any previous interim accounting
   records that are locally stored for delivery, if a new record is
   being generated for the same session.  This ensures that only one
   pending interim record can exist on an access device for any given
   session.

   A particular value of Accounting-Sub-Session-Id MUST appear only in
   one sequence of accounting records from a Diameter client, except for
   the purposes of retransmission.  The one sequence that is sent MUST
   be either one record with Accounting-Record-Type AVP set to the value
   EVENT_RECORD or several records starting with one having the value
   START_RECORD, followed by zero or more INTERIM_RECORDs and a single
   STOP_RECORD.  A particular Diameter application specification MUST
   define the type of sequences that MUST be used.

9.6. Correlation of Accounting Records

If an application uses accounting messages, it can correlate accounting records with a specific application session by using the Session-Id of the particular application session in the accounting messages. Accounting messages MAY also use a different Session-Id from that of the application sessions, in which case, other session- related information is needed to perform correlation. In cases where an application requires multiple accounting sub- sessions, an Accounting-Sub-Session-Id AVP is used to differentiate each sub-session. The Session-Id would remain constant for all sub- sessions and is used to correlate all the sub-sessions to a particular application session. Note that receiving a STOP_RECORD
Top   ToC   RFC6733 - Page 127
   with no Accounting-Sub-Session-Id AVP when sub-sessions were
   originally used in the START_RECORD messages implies that all sub-
   sessions are terminated.

   There are also cases where an application needs to correlate multiple
   application sessions into a single accounting record; the accounting
   record may span multiple different Diameter applications and sessions
   used by the same user at a given time.  In such cases, the Acct-
   Multi-Session-Id AVP is used.  The Acct-Multi-Session-Id AVP SHOULD
   be signaled by the server to the access device (typically, during
   authorization) when it determines that a request belongs to an
   existing session.  The access device MUST then include the Acct-
   Multi-Session-Id AVP in all subsequent accounting messages.

   The Acct-Multi-Session-Id AVP MAY include the value of the original
   Session-Id.  Its contents are implementation specific, but the MUST
   be globally unique across other Acct-Multi-Session-Ids and MUST NOT
   change during the life of a session.

   A Diameter application document MUST define the exact concept of a
   session that is being accounted, and it MAY define the concept of a
   multi-session.  For instance, the NASREQ DIAMETER application treats
   a single PPP connection to a Network Access Server as one session and
   a set of Multilink PPP sessions as one multi-session.

9.7. Accounting Command Codes

This section defines Command Code values that MUST be supported by all Diameter implementations that provide accounting services.

9.7.1. Accounting-Request

The Accounting-Request (ACR) command, indicated by the Command Code field set to 271 and the Command Flags' 'R' bit set, is sent by a Diameter node, acting as a client, in order to exchange accounting information with a peer. In addition to the AVPs listed below, Accounting-Request messages SHOULD include service-specific accounting AVPs.
Top   ToC   RFC6733 - Page 128
      Message Format

         <ACR> ::= < Diameter Header: 271, REQ, PXY >
                   < Session-Id >
                   { Origin-Host }
                   { Origin-Realm }
                   { Destination-Realm }
                   { Accounting-Record-Type }
                   { Accounting-Record-Number }
                   [ Acct-Application-Id ]
                   [ Vendor-Specific-Application-Id ]
                   [ User-Name ]
                   [ Destination-Host ]
                   [ Accounting-Sub-Session-Id ]
                   [ Acct-Session-Id ]
                   [ Acct-Multi-Session-Id ]
                   [ Acct-Interim-Interval ]
                   [ Accounting-Realtime-Required ]
                   [ Origin-State-Id ]
                   [ Event-Timestamp ]
                 * [ Proxy-Info ]
                 * [ Route-Record ]
                 * [ AVP ]

9.7.2. Accounting-Answer

The Accounting-Answer (ACA) command, indicated by the Command Code field set to 271 and the Command Flags' 'R' bit cleared, is used to acknowledge an Accounting-Request command. The Accounting-Answer command contains the same Session-Id as the corresponding request. Only the target Diameter server, known as the home Diameter server, SHOULD respond with the Accounting-Answer command. In addition to the AVPs listed below, Accounting-Answer messages SHOULD include service-specific accounting AVPs.
Top   ToC   RFC6733 - Page 129
      Message Format

         <ACA> ::= < Diameter Header: 271, PXY >
                   < Session-Id >
                   { Result-Code }
                   { Origin-Host }
                   { Origin-Realm }
                   { Accounting-Record-Type }
                   { Accounting-Record-Number }
                   [ Acct-Application-Id ]
                   [ Vendor-Specific-Application-Id ]
                   [ User-Name ]
                   [ Accounting-Sub-Session-Id ]
                   [ Acct-Session-Id ]
                   [ Acct-Multi-Session-Id ]
                   [ Error-Message ]
                   [ Error-Reporting-Host ]
                   [ Failed-AVP ]
                   [ Acct-Interim-Interval ]
                   [ Accounting-Realtime-Required ]
                   [ Origin-State-Id ]
                   [ Event-Timestamp ]
                 * [ Proxy-Info ]
                 * [ AVP ]

9.8. Accounting AVPs

This section contains AVPs that describe accounting usage information related to a specific session.

9.8.1. Accounting-Record-Type AVP

The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated and contains the type of accounting record being sent. The following values are currently defined for the Accounting-Record-Type AVP: EVENT_RECORD 1 An Accounting Event Record is used to indicate that a one-time event has occurred (meaning that the start and end of the event are simultaneous). This record contains all information relevant to the service, and it is the only record of the service.
Top   ToC   RFC6733 - Page 130
   START_RECORD 2

      Accounting Start, Interim, and Stop Records are used to indicate
      that a service of a measurable length has been given.  An
      Accounting Start Record is used to initiate an accounting session
      and contains accounting information that is relevant to the
      initiation of the session.

   INTERIM_RECORD 3

      An Interim Accounting Record contains cumulative accounting
      information for an existing accounting session.  Interim
      Accounting Records SHOULD be sent every time a re-authentication
      or re-authorization occurs.  Further, additional interim record
      triggers MAY be defined by application-specific Diameter
      applications.  The selection of whether to use INTERIM_RECORD
      records is done by the Acct-Interim-Interval AVP.

   STOP_RECORD 4

      An Accounting Stop Record is sent to terminate an accounting
      session and contains cumulative accounting information relevant to
      the existing session.

9.8.2. Acct-Interim-Interval AVP

The Acct-Interim-Interval AVP (AVP Code 85) is of type Unsigned32 and is sent from the Diameter home authorization server to the Diameter client. The client uses information in this AVP to decide how and when to produce accounting records. With different values in this AVP, service sessions can result in one, two, or two+N accounting records, based on the needs of the home organization. The following accounting record production behavior is directed by the inclusion of this AVP: 1. The omission of the Acct-Interim-Interval AVP or its inclusion with Value field set to 0 means that EVENT_RECORD, START_RECORD, and STOP_RECORD are produced, as appropriate for the service. 2. The inclusion of the AVP with Value field set to a non-zero value means that INTERIM_RECORD records MUST be produced between the START_RECORD and STOP_RECORD records. The Value field of this AVP is the nominal interval between these records in seconds. The Diameter node that originates the accounting information, known as the client, MUST produce the first INTERIM_RECORD record roughly at the time when this nominal interval has elapsed from
Top   ToC   RFC6733 - Page 131
       the START_RECORD, the next one again as the interval has elapsed
       once more, and so on until the session ends and a STOP_RECORD
       record is produced.

       The client MUST ensure that the interim record production times
       are randomized so that large accounting message storms are not
       created either among records or around a common service start
       time.

9.8.3. Accounting-Record-Number AVP

The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32 and identifies this record within one session. As Session-Id AVPs are globally unique, the combination of Session-Id and Accounting- Record-Number AVPs is also globally unique and can be used in matching accounting records with confirmations. An easy way to produce unique numbers is to set the value to 0 for records of type EVENT_RECORD and START_RECORD and set the value to 1 for the first INTERIM_RECORD, 2 for the second, and so on until the value for STOP_RECORD is one more than for the last INTERIM_RECORD.

9.8.4. Acct-Session-Id AVP

The Acct-Session-Id AVP (AVP Code 44) is of type OctetString is only used when RADIUS/Diameter translation occurs. This AVP contains the contents of the RADIUS Acct-Session-Id attribute.

9.8.5. Acct-Multi-Session-Id AVP

The Acct-Multi-Session-Id AVP (AVP Code 50) is of type UTF8String, following the format specified in Section 8.8. The Acct-Multi- Session-Id AVP is used to link multiple related accounting sessions, where each session would have a unique Session-Id but the same Acct- Multi-Session-Id AVP. This AVP MAY be returned by the Diameter server in an authorization answer, and it MUST be used in all accounting messages for the given session.

9.8.6. Accounting-Sub-Session-Id AVP

The Accounting-Sub-Session-Id AVP (AVP Code 287) is of type Unsigned64 and contains the accounting sub-session identifier. The combination of the Session-Id and this AVP MUST be unique per sub- session, and the value of this AVP MUST be monotonically increased by one for all new sub-sessions. The absence of this AVP implies no sub-sessions are in use, with the exception of an Accounting-Request whose Accounting-Record-Type is set to STOP_RECORD. A STOP_RECORD message with no Accounting-Sub-Session-Id AVP present will signal the termination of all sub-sessions for a given Session-Id.
Top   ToC   RFC6733 - Page 132

9.8.7. Accounting-Realtime-Required AVP

The Accounting-Realtime-Required AVP (AVP Code 483) is of type Enumerated and is sent from the Diameter home authorization server to the Diameter client or in the Accounting-Answer from the accounting server. The client uses information in this AVP to decide what to do if the sending of accounting records to the accounting server has been temporarily prevented due to, for instance, a network problem. DELIVER_AND_GRANT 1 The AVP with Value field set to DELIVER_AND_GRANT means that the service MUST only be granted as long as there is a connection to an accounting server. Note that the set of alternative accounting servers are treated as one server in this sense. Having to move the accounting record stream to a backup server is not a reason to discontinue the service to the user. GRANT_AND_STORE 2 The AVP with Value field set to GRANT_AND_STORE means that service SHOULD be granted if there is a connection, or as long as records can still be stored as described in Section 9.4. This is the default behavior if the AVP isn't included in the reply from the authorization server. GRANT_AND_LOSE 3 The AVP with Value field set to GRANT_AND_LOSE means that service SHOULD be granted even if the records cannot be delivered or stored.

10. AVP Occurrence Tables

The following tables present the AVPs defined in this document and specify in which Diameter messages they MAY or MAY NOT be present. AVPs that occur only inside a Grouped AVP are not shown in these tables. The tables use the following symbols: 0 The AVP MUST NOT be present in the message. 0+ Zero or more instances of the AVP MAY be present in the message.
Top   ToC   RFC6733 - Page 133
   0-1   Zero or one instance of the AVP MAY be present in the message.
         It is considered an error if there are more than one instance
         of the AVP.

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

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

10.1. Base Protocol Command AVP Table

The table in this section is limited to the non-Accounting Command Codes defined in this specification. +-----------------------------------------------+ | Command Code | +---+---+---+---+---+---+---+---+---+---+---+---+ Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| --------------------+---+---+---+---+---+---+---+---+---+---+---+---+ Acct-Interim- |0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 | Interval | | | | | | | | | | | | | Accounting-Realtime-|0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 | Required | | | | | | | | | | | | | Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 | Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Auth-Request-Type |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Auth-Session-State |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Authorization- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Lifetime | | | | | | | | | | | | | Class |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0+ |0+ | Destination-Host |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |0-1|0 | Destination-Realm |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 | Disconnect-Cause |0 |0 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Error-Message |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1| Error-Reporting-Host|0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1| Failed-AVP |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1| Firmware-Revision |0-1|0-1|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Host-IP-Address |1+ |1+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Inband-Security-Id |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Multi-Round-Time-Out|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Top   ToC   RFC6733 - Page 134
   Origin-Host         |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |
   Origin-Realm        |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |
   Origin-State-Id     |0-1|0-1|0  |0  |0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|
   Product-Name        |1  |1  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Proxy-Info          |0  |0  |0  |0  |0  |0  |0+ |0+ |0+ |0+ |0+ |0+ |
   Redirect-Host       |0  |0  |0  |0  |0  |0  |0  |0+ |0  |0+ |0  |0+ |
   Redirect-Host-Usage |0  |0  |0  |0  |0  |0  |0  |0-1|0  |0-1|0  |0-1|
   Redirect-Max-Cache- |0  |0  |0  |0  |0  |0  |0  |0-1|0  |0-1|0  |0-1|
     Time              |   |   |   |   |   |   |   |   |   |   |   |   |
   Result-Code         |0  |1  |0  |1  |0  |1  |0  |1  |0  |1  |0  |1  |
   Re-Auth-Request-Type|0  |0  |0  |0  |0  |0  |1  |0  |0  |0  |0  |0  |
   Route-Record        |0  |0  |0  |0  |0  |0  |0+ |0  |0+ |0  |0+ |0  |
   Session-Binding     |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Session-Id          |0  |0  |0  |0  |0  |0  |1  |1  |1  |1  |1  |1  |
   Session-Server-     |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
     Failover          |   |   |   |   |   |   |   |   |   |   |   |   |
   Session-Timeout     |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Supported-Vendor-Id |0+ |0+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Termination-Cause   |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |1  |0  |
   User-Name           |0  |0  |0  |0  |0  |0  |0-1|0-1|0-1|0-1|0-1|0-1|
   Vendor-Id           |1  |1  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Vendor-Specific-    |0+ |0+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
     Application-Id    |   |   |   |   |   |   |   |   |   |   |   |   |
   --------------------+---+---+---+---+---+---+---+---+---+---+---+---+

10.2. Accounting AVP Table

The table in this section is used to represent which AVPs defined in this document are to be present in the Accounting messages. These AVP occurrence requirements are guidelines, which may be expanded, and/or overridden by application-specific requirements in the Diameter applications documents.
Top   ToC   RFC6733 - Page 135
                                    +-----------+
                                    |  Command  |
                                    |    Code   |
                                    +-----+-----+
      Attribute Name                | ACR | ACA |
      ------------------------------+-----+-----+
      Acct-Interim-Interval         | 0-1 | 0-1 |
      Acct-Multi-Session-Id         | 0-1 | 0-1 |
      Accounting-Record-Number      | 1   | 1   |
      Accounting-Record-Type        | 1   | 1   |
      Acct-Session-Id               | 0-1 | 0-1 |
      Accounting-Sub-Session-Id     | 0-1 | 0-1 |
      Accounting-Realtime-Required  | 0-1 | 0-1 |
      Acct-Application-Id           | 0-1 | 0-1 |
      Auth-Application-Id           | 0   | 0   |
      Class                         | 0+  | 0+  |
      Destination-Host              | 0-1 | 0   |
      Destination-Realm             | 1   | 0   |
      Error-Reporting-Host          | 0   | 0+  |
      Event-Timestamp               | 0-1 | 0-1 |
      Failed-AVP                    | 0   | 0-1 |
      Origin-Host                   | 1   | 1   |
      Origin-Realm                  | 1   | 1   |
      Proxy-Info                    | 0+  | 0+  |
      Route-Record                  | 0+  | 0   |
      Result-Code                   | 0   | 1   |
      Session-Id                    | 1   | 1   |
      Termination-Cause             | 0   | 0   |
      User-Name                     | 0-1 | 0-1 |
      Vendor-Specific-Application-Id| 0-1 | 0-1 |
      ------------------------------+-----+-----+

11. IANA Considerations

This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the Diameter protocol, in accordance with [RFC5226]. Existing IANA registries and assignments put in place by RFC 3588 remain the same unless explicitly updated or deprecated in this section.

11.1. AVP Header

As defined in Section 4, the AVP header contains three fields that require IANA namespace management: the AVP Code, Vendor-ID, and Flags fields.
Top   ToC   RFC6733 - Page 136

11.1.1. AVP Codes

There are multiple namespaces. Vendors can have their own AVP Codes namespace that will be identified by their Vendor-ID (also known as Enterprise-Number), and they control the assignments of their vendor- specific AVP Codes within their own namespace. The absence of a Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF AVP Codes namespace, which is under IANA control. The AVP Codes and sometimes possible values in an AVP are controlled and maintained by IANA. AVP Code 0 is not used. AVP Codes 1-255 are managed separately as RADIUS Attribute Types. Where a Vendor-Specific AVP is implemented by more than one vendor, allocation of global AVPs should be encouraged instead. AVPs may be allocated following Expert Review (by a Designated Expert) with Specification Required [RFC5226]. A block allocation (release of more than three AVPs at a time for a given purpose) requires IETF Review [RFC5226].

11.1.2. AVP Flags

Section 4.1 describes the existing AVP Flags. The remaining bits can only be assigned via a Standards Action [RFC5226].

11.2. Diameter Header

11.2.1. Command Codes

For the Diameter header, the Command Code namespace allocation has changed. The new allocation rules are as follows: The Command Code values 256 - 8,388,607 (0x100 to 0x7fffff) are for permanent, standard commands, allocated by IETF Review [RFC5226]. The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved for vendor-specific Command Codes, to be allocated on a First Come, First Served basis by IANA [RFC5226]. The request to IANA for a Vendor-Specific Command Code SHOULD include a reference to a publicly available specification that documents the command in sufficient detail to aid in interoperability between independent implementations. If the specification cannot be made publicly available, the request for a vendor-specific Command Code MUST include the contact information of persons and/or entities responsible for authoring and maintaining the command.
Top   ToC   RFC6733 - Page 137
      The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe
      - 0xffffff) are reserved for experimental commands.  As these
      codes are only for experimental and testing purposes, no guarantee
      is made for interoperability between Diameter peers using
      experimental commands.

11.2.2. Command Flags

Section 3 describes the existing Command Flags field. The remaining bits can only be assigned via a Standards Action [RFC5226].

11.3. AVP Values

For AVP values, the Experimental-Result-Code AVP value allocation has been added; see Section 11.3.1. The old AVP value allocation rule, IETF Consensus, has been updated to IETF Review as per [RFC5226], and affected AVPs are listed as reminders.

11.3.1. Experimental-Result-Code AVP

Values for this AVP are purely local to the indicated vendor, and no IANA registry is maintained for them.

11.3.2. Result-Code AVP Values

New values are available for assignment via IETF Review [RFC5226].

11.3.3. Accounting-Record-Type AVP Values

New values are available for assignment via IETF Review [RFC5226].

11.3.4. Termination-Cause AVP Values

New values are available for assignment via IETF Review [RFC5226].

11.3.5. Redirect-Host-Usage AVP Values

New values are available for assignment via IETF Review [RFC5226].

11.3.6. Session-Server-Failover AVP Values

New values are available for assignment via IETF Review [RFC5226].

11.3.7. Session-Binding AVP Values

New values are available for assignment via IETF Review [RFC5226].
Top   ToC   RFC6733 - Page 138

11.3.8. Disconnect-Cause AVP Values

New values are available for assignment via IETF Review [RFC5226].

11.3.9. Auth-Request-Type AVP Values

New values are available for assignment via IETF Review [RFC5226].

11.3.10. Auth-Session-State AVP Values

New values are available for assignment via IETF Review [RFC5226].

11.3.11. Re-Auth-Request-Type AVP Values

New values are available for assignment via IETF Review [RFC5226].

11.3.12. Accounting-Realtime-Required AVP Values

New values are available for assignment via IETF Review [RFC5226].

11.3.13. Inband-Security-Id AVP (code 299)

The use of this AVP has been deprecated.

11.4. _diameters Service Name and Port Number Registration

IANA has registered the "_diameters" service name and assigned port numbers for TLS/TCP and DTLS/SCTP according to the guidelines given in [RFC6335]. Service Name: _diameters Transport Protocols: TCP, SCTP Assignee: IESG <iesg@ietf.org> Contact: IETF Chair <chair@ietf.org> Description: Diameter over TLS/TCP and DTLS/SCTP Reference: RFC 6733 Port Number: 5868, from the User Range
Top   ToC   RFC6733 - Page 139

11.5. SCTP Payload Protocol Identifiers

Two SCTP payload protocol identifiers have been registered in the SCTP Payload Protocol Identifiers registry: Value | SCTP Payload Protocol Identifier -------|----------------------------------- 46 | Diameter in a SCTP DATA chunk 47 | Diameter in a DTLS/SCTP DATA chunk

11.6. S-NAPTR Parameters

The following tag has been registered in the S-NAPTR Application Protocol Tags registry: Tag | Protocol -------------------|--------- diameter.dtls.sctp | DTLS/SCTP

12. Diameter Protocol-Related Configurable Parameters

This section contains the configurable parameters that are found throughout this document: Diameter Peer A Diameter entity MAY communicate with peers that are statically configured. A statically configured Diameter peer would require that either the IP address or the fully qualified domain name (FQDN) be supplied, which would then be used to resolve through DNS. Routing Table A Diameter proxy server routes messages based on the realm portion of a Network Access Identifier (NAI). The server MUST have a table of Realm Names, and the address of the peer to which the message must be forwarded. The routing table MAY also include a "default route", which is typically used for all messages that cannot be locally processed. Tc timer The Tc timer controls the frequency that transport connection attempts are done to a peer with whom no active transport connection exists. The recommended value is 30 seconds.
Top   ToC   RFC6733 - Page 140

13. Security Considerations

The Diameter base protocol messages SHOULD be secured by using TLS [RFC5246] or DTLS/SCTP [RFC6083]. Additional security mechanisms such as IPsec [RFC4301] MAY also be deployed to secure connections between peers. However, all Diameter base protocol implementations MUST support the use of TLS/TCP and DTLS/SCTP, and the Diameter protocol MUST NOT be used without one of TLS, DTLS, or IPsec. If a Diameter connection is to be protected via TLS/TCP and DTLS/SCTP or IPsec, then TLS/TCP and DTLS/SCTP or IPsec/IKE SHOULD begin prior to any Diameter message exchange. All security parameters for TLS/ TCP and DTLS/SCTP or IPsec are configured independent of the Diameter protocol. All Diameter messages will be sent through the TLS/TCP and DTLS/SCTP or IPsec connection after a successful setup. For TLS/TCP and DTLS/SCTP connections to be established in the open state, the CER/CEA exchange MUST include an Inband-Security-ID AVP with a value of TLS/TCP and DTLS/SCTP. The TLS/TCP and DTLS/SCTP handshake will begin when both ends successfully reach the open state, after completion of the CER/CEA exchange. If the TLS/TCP and DTLS/SCTP handshake is successful, all further messages will be sent via TLS/TCP and DTLS/SCTP. If the handshake fails, both ends MUST move to the closed state. See Section 13.1 for more details.

13.1. TLS/TCP and DTLS/SCTP Usage

Diameter nodes using TLS/TCP and DTLS/SCTP for security MUST mutually authenticate as part of TLS/TCP and DTLS/SCTP session establishment. In order to ensure mutual authentication, the Diameter node acting as the TLS/TCP and DTLS/SCTP server MUST request a certificate from the Diameter node acting as TLS/TCP and DTLS/SCTP client, and the Diameter node acting as the TLS/TCP and DTLS/SCTP client MUST be prepared to supply a certificate on request. Diameter nodes MUST be able to negotiate the following TLS/TCP and DTLS/SCTP cipher suites: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA Diameter nodes SHOULD be able to negotiate the following TLS/TCP and DTLS/SCTP cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA
Top   ToC   RFC6733 - Page 141
   Note that it is quite possible that support for the
   TLS_RSA_WITH_AES_128_CBC_SHA cipher suite will be REQUIRED at some
   future date.  Diameter nodes MAY negotiate other TLS/TCP and DTLS/
   SCTP cipher suites.

   If public key certificates are used for Diameter security (for
   example, with TLS), the value of the expiration times in the routing
   and peer tables MUST NOT be greater than the expiry time in the
   relevant certificates.

13.2. Peer-to-Peer Considerations

As with any peer-to-peer protocol, proper configuration of the trust model within a Diameter peer is essential to security. When certificates are used, it is necessary to configure the root certificate authorities trusted by the Diameter peer. These root CAs are likely to be unique to Diameter usage and distinct from the root CAs that might be trusted for other purposes such as Web browsing. In general, it is expected that those root CAs will be configured so as to reflect the business relationships between the organization hosting the Diameter peer and other organizations. As a result, a Diameter peer will typically not be configured to allow connectivity with any arbitrary peer. With certificate authentication, Diameter peers may not be known beforehand and therefore peer discovery may be required.

13.3. AVP Considerations

Diameter AVPs often contain security-sensitive data; for example, user passwords and location data, network addresses and cryptographic keys. The following AVPs defined in this document are considered to be security-sensitive: o Acct-Interim-Interval o Accounting-Realtime-Required o Acct-Multi-Session-Id o Accounting-Record-Number o Accounting-Record-Type o Accounting-Session-Id o Accounting-Sub-Session-Id o Class
Top   ToC   RFC6733 - Page 142
   o  Session-Id

   o  Session-Binding

   o  Session-Server-Failover

   o  User-Name

   Diameter messages containing these or any other AVPs considered to be
   security-sensitive MUST only be sent protected via mutually
   authenticated TLS or IPsec.  In addition, those messages MUST NOT be
   sent via intermediate nodes unless there is end-to-end security
   between the originator and recipient or the originator has locally
   trusted configuration that indicates that end-to-end security is not
   needed.  For example, end-to-end security may not be required in the
   case where an intermediary node is known to be operated as part of
   the same administrative domain as the endpoints so that an ability to
   successfully compromise the intermediary would imply a high
   probability of being able to compromise the endpoints as well.  Note
   that no end-to-end security mechanism is specified in this document.

14. References

14.1. Normative References

[FLOATPOINT] Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Standard 754-1985", August 1985. [IANAADFAM] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
Top   ToC   RFC6733 - Page 143
   [RFC3539]  Aboba, B. and J. Wood, "Authentication, Authorization and
              Accounting (AAA) Transport Profile", RFC 3539, June 2003.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3958]  Daigle, L. and A. Newton, "Domain-Based Application
              Service Location Using SRV RRs and the Dynamic Delegation
              Discovery Service (DDDS)", RFC 3958, January 2005.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC4004]  Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
              P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
              August 2005.

   [RFC4005]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
              "Diameter Network Access Server Application", RFC 4005,
              August 2005.

   [RFC4006]  Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
              Loughney, "Diameter Credit-Control Application", RFC 4006,
              August 2005.

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

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
Top   ToC   RFC6733 - Page 144
   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC5729]  Korhonen, J., Jones, M., Morand, L., and T. Tsou,
              "Clarifications on the Routing of Diameter Requests Based
              on the Username and the Realm", RFC 5729, December 2009.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, August 2010.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891, August 2010.

   [RFC6083]  Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
              Transport Layer Security (DTLS) for Stream Control
              Transmission Protocol (SCTP)", RFC 6083, January 2011.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC6408]  Jones, M., Korhonen, J., and L. Morand, "Diameter
              Straightforward-Naming Authority Pointer (S-NAPTR) Usage",
              RFC 6408, November 2011.

14.2. Informative References

[ENTERPRISE] IANA, "SMI Network Management Private Enterprise Codes", <http://www.iana.org/assignments/enterprise-numbers>. [IANATCV] IANA, "Termination-Cause AVP Values (code 295)", <http://www.iana.org/assignments/aaa-parameters/ aaa-parameters.xml#aaa-parameters-16>. [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
Top   ToC   RFC6733 - Page 145
   [RFC2782]     Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
                 for specifying the location of services (DNS SRV)",
                 RFC 2782, February 2000.

   [RFC2865]     Rigney, C., Willens, S., Rubens, A., and W. Simpson,
                 "Remote Authentication Dial In User Service (RADIUS)",
                 RFC 2865, June 2000.

   [RFC2866]     Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [RFC2869]     Rigney, C., Willats, W., and P. Calhoun, "RADIUS
                 Extensions", RFC 2869, June 2000.

   [RFC2881]     Mitton, D. and M. Beadles, "Network Access Server
                 Requirements Next Generation (NASREQNG) NAS Model",
                 RFC 2881, July 2000.

   [RFC2975]     Aboba, B., Arkko, J., and D. Harrington, "Introduction
                 to Accounting Management", RFC 2975, October 2000.

   [RFC2989]     Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann,
                 P., Shiino, H., Walsh, P., Zorn, G., Dommety, G.,
                 Perkins, C., Patil, B., Mitton, D., Manning, S.,
                 Beadles, M., Chen, X., Sivalingham, S., Hameed, A.,
                 Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu,
                 R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba,
                 S., and E. Jaques, "Criteria for Evaluating AAA
                 Protocols for Network Access", RFC 2989, November 2000.

   [RFC3162]     Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
                 RFC 3162, August 2001.

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

   [RFC4301]     Kent, S. and K. Seo, "Security Architecture for the
                 Internet Protocol", RFC 4301, December 2005.

   [RFC4690]     Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review
                 and Recommendations for Internationalized Domain Names
                 (IDNs)", RFC 4690, September 2006.

   [RFC5176]     Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
                 Aboba, "Dynamic Authorization Extensions to Remote
                 Authentication Dial In User Service (RADIUS)",
                 RFC 5176, January 2008.
Top   ToC   RFC6733 - Page 146
   [RFC5461]     Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
                 February 2009.

   [RFC5905]     Mills, D., Martin, J., Burbank, J., and W. Kasch,
                 "Network Time Protocol Version 4: Protocol and
                 Algorithms Specification", RFC 5905, June 2010.

   [RFC5927]     Gont, F., "ICMP Attacks against TCP", RFC 5927,
                 July 2010.

   [RFC6335]     Cotton, M., Eggert, L., Touch, J., Westerlund, M., and
                 S. Cheshire, "Internet Assigned Numbers Authority
                 (IANA) Procedures for the Management of the Service
                 Name and Transport Protocol Port Number Registry",
                 BCP 165, RFC 6335, August 2011.

   [RFC6737]     Kang, J. and G. Zorn, "The Diameter Capabilities Update
                 Application", RFC 6737, October 2012.
Top   ToC   RFC6733 - Page 147

Appendix A. Acknowledgements

A.1. This Document

The authors would like to thank the following people that have provided proposals and contributions to this document: To Vishnu Ram and Satendra Gera for their contributions on capabilities updates, predictive loop avoidance, as well as many other technical proposals. To Tolga Asveren for his insights and contributions on almost all of the proposed solutions incorporated into this document. To Timothy Smith for helping on the capabilities Update and other topics. To Tony Zhang for providing fixes to loopholes on composing Failed-AVPs as well as many other issues and topics. To Jan Nordqvist for clearly stating the usage of Application Ids. To Anders Kristensen for providing needed technical opinions. To David Frascone for providing invaluable review of the document. To Mark Jones for providing clarifying text on vendor command codes and other vendor-specific indicators. To Victor Pascual and Sebastien Decugis for new text and recommendations on SCTP/DTLS. To Jouni Korhonen for taking over the editing task and resolving last bits from versions 27 through 29. Special thanks to the Diameter extensibility design team, which helped resolve the tricky question of mandatory AVPs and ABNF semantics. The members of this team are as follows: Avi Lior, Jari Arkko, Glen Zorn, Lionel Morand, Mark Jones, Tolga Asveren, Jouni Korhonen, and Glenn McGregor. Special thanks also to people who have provided invaluable comments and inputs especially in resolving controversial issues: Glen Zorn, Yoshihiro Ohba, Marco Stura, Stephen Farrel, Pete Resnick, Peter Saint-Andre, Robert Sparks, Krishna Prasad, Sean Turner, Barry Leiba, and Pasi Eronen. Finally, we would like to thank the original authors of this document: Pat Calhoun, John Loughney, Jari Arkko, Erik Guttman, and Glen Zorn. Their invaluable knowledge and experience has given us a robust and flexible AAA protocol that many people have seen great value in adopting. We greatly appreciate their support and stewardship for the continued improvements of Diameter as a protocol. We would also like to extend our gratitude to folks aside from the authors who have
Top   ToC   RFC6733 - Page 148
   assisted and contributed to the original version of this document.
   Their efforts significantly contributed to the success of Diameter.

A.2. RFC 3588

The authors would like to thank Nenad Trifunovic, Tony Johansson and Pankaj Patel for their participation in the pre-IETF Document Reading Party. Allison Mankin, Jonathan Wood, and Bernard Aboba provided invaluable assistance in working out transport issues and this was also the case with Steven Bellovin in the security area. Paul Funk and David Mitton were instrumental in getting the Peer State Machine correct, and our deep thanks go to them for their time. Text in this document was also provided by Paul Funk, Mark Eklund, Mark Jones, and Dave Spence. Jacques Caron provided many great comments as a result of a thorough review of the spec. The authors would also like to acknowledge the following people for their contribution in the development of the Diameter protocol: Allan C. Rubens, Haseeb Akhtar, William Bulley, Stephen Farrell, David Frascone, Daniel C. Fox, Lol Grant, Ignacio Goyret, Nancy Greene, Peter Heitman, Fredrik Johansson, Mark Jones, Martin Julien, Bob Kopacz, Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, John Schnizlein, Sumit Vakil, John R. Vollbrecht, and Jeff Weisberg. Finally, Pat Calhoun would like to thank Sun Microsystems since most of the effort put into this document was done while he was in their employ.

Appendix B. S-NAPTR Example

As an example, consider a client that wishes to resolve aaa: ex1.example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned: ;; order pref flags service regexp replacement IN NAPTR 50 50 "s" "aaa:diameter.tls.tcp" "" _diameter._tls.ex1.example.com IN NAPTR 100 50 "s" "aaa:diameter.tcp" "" _aaa._tcp.ex1.example.com IN NAPTR 150 50 "s" "aaa:diameter.sctp" "" _diameter._sctp.ex1.example.com This indicates that the server supports TLS, TCP, and SCTP in that order. If the client supports TLS, TLS will be used, targeted to a
Top   ToC   RFC6733 - Page 149
   host determined by an SRV lookup of _diameter._tls.ex1.example.com.
   That lookup would return:

    ;;       Priority  Weight  Port    Target
    IN SRV   0         1       5060    server1.ex1.example.com
    IN SRV   0         2       5060    server2.ex1.example.com

   As an alternative example, a client that wishes to resolve aaa:
   ex2.example.com.  The client performs a NAPTR query for that domain,
   and the following NAPTR records are returned:

    ;;        order pref flags service   regexp replacement
    IN NAPTR  150   50   "a"   "aaa:diameter.tls.tcp"  ""
                 server1.ex2.example.com
    IN NAPTR  150   50   "a"   "aaa:diameter.tls.tcp"  ""
                 server2.ex2.example.com

   This indicates that the server supports TCP available at the returned
   host names.

Appendix C. Duplicate Detection

As described in Section 9.4, accounting record duplicate detection is based on session identifiers. Duplicates can appear for various reasons: o Failover to an alternate server. Where close to real-time performance is required, failover thresholds need to be kept low. This may lead to an increased likelihood of duplicates. Failover can occur at the client or within Diameter agents. o Failure of a client or agent after sending a record from non- volatile memory, but prior to receipt of an application-layer ACK and deletion of the record to be sent. This will result in retransmission of the record soon after the client or agent has rebooted. o Duplicates received from RADIUS gateways. Since the retransmission behavior of RADIUS is not defined within [RFC2865], the likelihood of duplication will vary according to the implementation. o Implementation problems and misconfiguration. The T flag is used as an indication of an application-layer retransmission event, e.g., due to failover to an alternate server. It is defined only for request messages sent by Diameter clients or agents. For instance, after a reboot, a client may not know whether
Top   ToC   RFC6733 - Page 150
   it has already tried to send the accounting records in its non-
   volatile memory before the reboot occurred.  Diameter servers MAY use
   the T flag as an aid when processing requests and detecting duplicate
   messages.  However, servers that do this MUST ensure that duplicates
   are found even when the first transmitted request arrives at the
   server after the retransmitted request.  It can be used only in cases
   where no answer has been received from the server for a request and
   the request is sent again, (e.g., due to a failover to an alternate
   peer, due to a recovered primary peer or due to a client re-sending a
   stored record from non-volatile memory such as after reboot of a
   client or agent).

   In some cases, the Diameter accounting server can delay the duplicate
   detection and accounting record processing until a post-processing
   phase takes place.  At that time records are likely to be sorted
   according to the included User-Name and duplicate elimination is easy
   in this case.  In other situations, it may be necessary to perform
   real-time duplicate detection, such as when credit limits are imposed
   or real-time fraud detection is desired.

   In general, only generation of duplicates due to failover or re-
   sending of records in non-volatile storage can be reliably detected
   by Diameter clients or agents.  In such cases, the Diameter client or
   agents can mark the message as a possible duplicate by setting the T
   flag.  Since the Diameter server is responsible for duplicate
   detection, it can choose whether or not to make use of the T flag, in
   order to optimize duplicate detection.  Since the T flag does not
   affect interoperability, and it may not be needed by some servers,
   generation of the T flag is REQUIRED for Diameter clients and agents,
   but it MAY be implemented by Diameter servers.

   As an example, it can be usually be assumed that duplicates appear
   within a time window of longest recorded network partition or device
   fault, perhaps a day.  So only records within this time window need
   to be looked at in the backward direction.  Secondly, hashing
   techniques or other schemes, such as the use of the T flag in the
   received messages, may be used to eliminate the need to do a full
   search even in this set except for rare cases.

   The following is an example of how the T flag may be used by the
   server to detect duplicate requests.

      A Diameter server MAY check the T flag of the received message to
      determine if the record is a possible duplicate.  If the T flag is
      set in the request message, the server searches for a duplicate
      within a configurable duplication time window backward and
      forward.  This limits database searching to those records where
      the T flag is set.  In a well-run network, network partitions and
Top   ToC   RFC6733 - Page 151
      device faults will presumably be rare events, so this approach
      represents a substantial optimization of the duplicate detection
      process.  During failover, it is possible for the original record
      to be received after the T-flag-marked record, due to differences
      in network delays experienced along the path by the original and
      duplicate transmissions.  The likelihood of this occurring
      increases as the failover interval is decreased.  In order to be
      able to detect duplicates that are out of order, the Diameter
      server should use backward and forward time windows when
      performing duplicate checking for the T-flag-marked request.  For
      example, in order to allow time for the original record to exit
      the network and be recorded by the accounting server, the Diameter
      server can delay processing records with the T flag set until a
      time period TIME_WAIT + RECORD_PROCESSING_TIME has elapsed after
      the closing of the original transport connection.  After this time
      period, it may check the T-flag-marked records against the
      database with relative assurance that the original records, if
      sent, have been received and recorded.

Appendix D. Internationalized Domain Names

To be compatible with the existing DNS infrastructure and simplify host and domain name comparison, Diameter identities (FQDNs) are represented in ASCII form. This allows the Diameter protocol to fall in-line with the DNS strategy of being transparent from the effects of Internationalized Domain Names (IDNs) by following the recommendations in [RFC4690] and [RFC5890]. Applications that provide support for IDNs outside of the Diameter protocol but interacting with it SHOULD use the representation and conversion framework described in [RFC5890], [RFC5891], and [RFC3492].
Top   ToC   RFC6733 - Page 152

Authors' Addresses

Victor Fajardo (editor) Telcordia Technologies One Telcordia Drive, 1S-222 Piscataway, NJ 08854 USA Phone: +1-908-421-1845 EMail: vf0213@gmail.com Jari Arkko Ericsson Research 02420 Jorvas Finland Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com John Loughney Nokia Research Center 955 Page Mill Road Palo Alto, CA 94304 US Phone: +1-650-283-8068 EMail: john.loughney@nokia.com Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand Phone: +66 (0) 87-0404617 EMail: glenzorn@gmail.com