RFC 6733
Diameter Base Protocol
Pages: 152
Proposed Standard
→ Errata
Obsoletes: 3588 5719
Updated by: 7075 8553
Proposed Standard
→ Errata
Obsoletes: 3588 5719
Updated by: 7075 8553
Part 5 of 5 – Pages 123 to 152
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.
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.
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
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
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.
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.
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.
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
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.
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.
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 |
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.
+-----------+
| 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.
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.
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].
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
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 chunk11.6. S-NAPTR Parameters
The following tag has been registered in the S-NAPTR Application Protocol Tags registry: Tag | Protocol -------------------|--------- diameter.dtls.sctp | DTLS/SCTP12. 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.
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
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
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.
[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.
[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.
[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.
[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.
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
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
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
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
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].
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