Name

AVP Code

Data Type

Vendor

Accounting-Auth-Method

406

Enumerated

IETF

Used to indicate the authentication method employed for a user. It is typically included in Accounting-Request (ACR) messages sent by a Network Access Server (NAS) to report the authentication method utilized during the session. This AVP corresponds to the MS-Acct-Auth-Type attribute defined in RADIUS [RFC 2548], ensuring compatibility between Diameter and RADIUS-based accounting systems.

Enumerated Values:

0 None: No authentication was performed.

1 PAP: Password Authentication Protocol.

2 CHAP: Challenge-Handshake Authentication Protocol.

3 MS-CHAP-1: Microsoft Challenge-Handshake Authentication Protocol v1.

4 MS-CHAP-2: Microsoft Challenge-Handshake Authentication Protocol v2.

5 EAP: Extensible Authentication Protocol.

Accounting-Input-Octets

363

Unsigned64

IETF

Reports the number of octets (bytes) received from the user during a session. It is primarily used in Diameter Accounting-Request (ACR) messages to track incoming data for accounting, billing, and auditing purposes. This AVP is applicable only in INTERIM_RECORD or STOP_RECORD accounting scenarios, as defined in [RFC 6733].

Accounting-Input-Packets

365

Unsigned64

IETF

Designed to track the number of packets received from the user during a session. It is commonly used in Diameter Accounting-Request (ACR) messages for accounting, billing, and session monitoring. This AVP is only valid in accounting records with an Accounting-Record-Type of INTERIM_RECORD or STOP_RECORD as specified in [RFC 6733].

Accounting-Output-Octets

364

Unsigned64

IETF

Used to track the number of bytes (octets) sent to the user during a session. It is utilized primarily in Diameter Accounting-Request (ACR) messages for accounting, billing, and session monitoring purposes. This AVP is valid only in accounting records with an Accounting-Record-Type of INTERIM_RECORD or STOP_RECORD as defined in [RFC 6733].

Accounting-Output-Packets

366

Unsigned64

IETF

Used to record the number of IP packets sent to the user during a session. It is primarily included in Diameter Accounting-Request (ACR) messages for accounting, billing, and session monitoring purposes. This AVP applies only to accounting records with an Accounting-Record-Type of INTERIM_RECORD or STOP_RECORD, as specified in [RFC 6733].

Acct-Authentic

45

Enumerated

IETF

Specifies how the user was authenticated during the session. It is primarily used in Diameter Accounting-Request (ACR) messages to log the authentication method for accounting, auditing, and billing purposes. This AVP is functionally equivalent to the MS-Acct-Auth-Type attribute in RADIUS and maintains consistency between Diameter and RADIUS-based accounting systems.

Enumerated Values:

0: RADIUS Authentication

1: Local Authentication

2: Remote Authentication

3: Diameter Authentication

4: No Authentication

Acct-Delay-Time

41

Unsigned32

IETF

Specifies the number of seconds a Diameter client has been attempting to send an Accounting-Request (ACR). This AVP does not track retransmissions at the transport level (e.g., TCP, SCTP). It is only included in cases where an ACR is delayed before transmission, making it optional for regular transmissions. Implementations should ensure precision when recording delay times, particularly in high-availability systems.

Acct-Link-Count

51

Unsigned32

IETF

Used to indicate the total number of links that have been active (either current or closed) within a multilink session at the time an accounting record is generated. Relevant only for sessions using multilink services. This AVP may be included in Accounting-Request (ACR) messages but is not mandatory. Commonly included in ACRs with Accounting-Record-Type = STOP_RECORD for session closure reporting. Correlated with Acct-Multi-Session-Id and Session-Id AVPs to group records within a session.

Acct-Session-Time

46

Unsigned32

IETF

Represents the duration of the current session in seconds. It is of type Unsigned32 and is used for accounting purposes in Diameter-based networks. This AVP is typically included in Accounting-Request (ACR) messages, but only when the Accounting-Record-Type is set to either:

• INTERIM_RECORD – for periodic updates during the session.

• STOP_RECORD – for final accounting details when the session ends.

Does not appear in START_RECORD types, as session duration cannot be determined at the start.

Acct-Tunnel-Connection

68

OctetString

IETF

Used to store an identifier assigned to a tunnel session. It allows systems to uniquely identify a tunnel session for auditing purposes. This AVP is typically utilized in conjunction with:

Tunnel-Client-Endpoint (Section 4.5.4) [RFC 7155]: Identifies the client-side endpoint of the tunnel.

Tunnel-Server-Endpoint (Section 4.5.5) [RFC 7155]: Identifies the server-side endpoint of the tunnel.

The encoding format depends on the Tunnel-Type AVP (Section 4.5.2) [RFC 7155].

Example: L2TP (Layer 2 Tunneling Protocol) might include Tunnel ID and Call ID encoded together. Typically used in tunneling protocols for VPNs, GRE, and L2TP sessions. 

Allows customized identifiers, making it versatile across different protocols and tunnel configurations.

Acct-Tunnel-Packets-Lost

86

Unsigned32

IETF

Representing the number of packets lost on a specific tunnel during a session. It is primarily used for monitoring, troubleshooting, and accounting purposes in tunneling protocols, ensuring data integrity and identifying packet loss issues. Typically included in Accounting-Request (ACR) messages for tunnel monitoring.

ARAP-Challenge-Response

84

OctetString

IETF

Containing an 8-octet response to the dial-in client's challenge during AppleTalk Remote Access Protocol (ARAP) authentication. This AVP is mandatory when the Framed-Protocol AVP (Section 4.4.10.1) [RFC 7155] is set to ARAP. It facilitates secure authentication by encrypting the client's challenge with the user's password as the key. Uses DES encryption with the user’s password as the encryption key to validate identity.

If the user’s password is less than 8 octets, it is padded with NULL octets before encryption.

ARAP-Features

71

OctetString

IETF

Used to define specific features supported in AppleTalk Remote Access Protocol (ARAP) sessions. It is typically included in the AA-Accept message when the Framed-Protocol AVP is set to ARAP. This AVP allows the Diameter server to communicate supported ARAP features to the client, facilitating capability negotiation for the session. Compliant with [RFC 2869] specifications for ARAP extensions in Diameter and RADIUS systems.

ARAP-Password

70

OctetString

IETF

Used to store the password for AppleTalk Remote Access Protocol (ARAP) authentication sessions. It is included in Diameter messages only when the Framed-Protocol AVP is set to ARAP and is specifically designed for ARAP authentication purposes. Mutually exclusive with User-Password and CHAP-Auth AVPs. Does not encrypt the password; transmission should rely on secure transport protocols such as IPSec, TLS, or SCTP. Compliant with [RFC 2869].

ARAP-Security

73

Unsigned32

IETF

Designed to provide security-related information for AppleTalk Remote Access Protocol (ARAP) sessions. This AVP may appear in an AA-Answer message under specific conditions:

• The Framed-Protocol AVP is set to ARAP.

• The Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH.

Should be transmitted over secure transport layers like IPSec, TLS, or SCTP to protect sensitive information. Compliant with [RFC 2869].

ARAP-Security-Data

74

OctetString

IETF

Used to transport security module challenge or response data for AppleTalk Remote Access Protocol (ARAP) sessions. This AVP is optional and may appear in the following Diameter messages: AA-Request (AAR), AA-Answer (AAA).

It is specifically included when:

• The Framed-Protocol AVP is set to ARAP.

• The Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH.

Should be transmitted using secure transport protocols such as TLS, IPSec, or SCTP to prevent unauthorized access. Works alongside the ARAP-Security AVP to form a challenge-response pair for secure authentication. Compliant with [RFC 7155].

ARAP-Zone-Access

72

Enumerated

IETF

Defines whether a user is granted AppleTalk Remote Access Protocol (ARAP) zone access. This AVP may be included in the AA-Accept message when the Framed-Protocol AVP is set to ARAP. 

Enumerated Values:

0 Denied: User is denied access to the requested zone.

1 Granted: User is granted access to the requested zone.

Aligned with RADIUS attributes defined in [RFC 2869] for consistency across protocols.

Callback-Id

20

UTF8String

IETF

Specifies the name of a place to be called. This information is meant to be interpreted by the Network Access Server (NAS). Not recommended for roaming environments due to NAS configuration dependency. Use Callback-Number AVP instead for greater compatibility.

Callback-Number

19

UTF8String

IETF

Contains a dialing string used for callback purposes. It allows specifying a callback number in an authentication or authorization request, indicating that a callback service is desired. This AVP MAY be used in an authentication and/or authorization request as a hint to the server that a callback service is desired. But the server is not required to honor the hint in the corresponding response.

Called-Station-Id

30

UTF8String

IETF

Used to identify the Layer 2 address that the user contacted in a request. Used to authorize access requests based solely on the called station identifier. Particularly useful when no User-Name AVP is provided. Can store phone numbers or MAC addresses, depending on the access method. It is commonly employed for dialup access scenarios and IEEE 802-based access. 

Calling-Station-Id

31

UTF8String

IETF

Used to specify the Layer 2 address from which the user connected during a request. It supports dialup access and IEEE 802-based access scenarios. May be included in AAR messages when Auth-Request-Type is set to AUTHORIZE_ONLY and User-Name AVP is absent. Can hold phone numbers or MAC addresses for different access methods.

CHAP-Algorithm

403

Enumerated

IETF

Specifies the algorithm identifier used for computing the CHAP response based on Challenge-Handshake Authentication Protocol (CHAP) as described in [RFC 1994].

This algorithm requires the CHAP-Response AVP to be included in the CHAP-Auth AVP.

Enumerated Values:

5 CHAP with MD5: Uses MD5 hashing for computing the CHAP response.

CHAP-Auth

402

Grouped

IETF

Contains information necessary for authenticating a user using the PPP Challenge-Handshake Authentication Protocol (CHAP) as defined in [RFC 1994]. CHAP authentication is vulnerable to dictionary attacks and replay attacks if not combined with secure transport layers (e.g., TLS).

The AVP structure is defined as follows:

CHAP-Algorithm (Mandatory, Enumerated): Specifies the algorithm used for computing the CHAP response. 

CHAP-Ident (Mandatory, OctetString): Provides the identifier for the CHAP challenge used during the authentication.

CHAP-Response (Optional, OctetString): Contains the CHAP response generated by the user for authentication validation.

CHAP-Challenge

60

OctetString

IETF

Contains the CHAP Challenge sent by the NAS (Network Access Server) to the CHAP peer during the Challenge-Handshake Authentication Protocol (CHAP) process, as defined in [RFC 1994]. The NAS dynamically generates the CHAP Challenge for each session to prevent replay attacks. If the CHAP-Auth AVP (AVP Code 402) is present, the CHAP-Challenge AVP must also be included.

CHAP-Ident

404

OctetString

IETF

Identifier used in the computation of the CHAP response, as specified in [RFC 1994]. It uniquely identifies the CHAP Challenge and ensures the integrity of the authentication process. If the CHAP-Auth AVP (AVP Code 402) is present, the CHAP-Ident AVP must also be included. The CHAP Identifier is strictly 1 octet in size, which must be enforced during implementation.

CHAP-Response

405

OctetString

IETF

Contains the 16-octet authentication data provided by the user in response to a CHAP challenge as specified in [RFC 1994]. It forms part of the CHAP authentication process and is used to verify the identity of the user. If the CHAP-Auth AVP (AVP Code 402) is present and uses MD5 as the algorithm, the CHAP-Response AVP must be included.

Configuration-Token

78

OctetString

IETF

Used to communicate a user profile type between a Diameter server and a Diameter Proxy Agent as part of an AA-Answer command. It specifies configuration details required to establish or enforce the user’s profile settings. This AVP is not intended for Diameter clients (NAS) and should only be sent between a Diameter server and a Proxy Agent. The format and interpretation of this AVP's data field depend on local configurations and are deployment-specific.

Connect-Info

77

UTF8String

IETF

Provides details about a user's connection. It may describe the connection type, speed, and other relevant characteristics. Depending on the message context, it may also include session quality statistics.

In AA-Request (AAR): Describes the nature of the user's connection, including connection speeds and optional connection-related information.

Example formats: 

"28800 V42BIS/LAPM"

"52000/31200 V90"

In Accounting-Request (ACR) with Accounting-Record-Type = STOP: Summarizes session quality metrics, which could include retransmissions, errors, or other relevant statistics. Inclusion is implementation-specific and depends on the NAS and session context.

QoS-Filter-Rule

407

QoSFilterRule

IETF

Defines Quality of Service (QoS) filter rules for configuring user-level QoS on a Network Access Server (NAS). The rules determine how packets are treated based on specific attributes such as direction, IP address, protocol, and Differentiated Services Code Point (DSCP) values. QoS-Filter-Rule uses a subset of the ipfw syntax from FreeBSD, extended for Diameter. Each rule consists of an action, direction, protocol, source, and destination attributes, with optional parameters like metering rates and DSCP values.

Parameters:

Rule (String): Complete QoS rule in text format.

Syntax: action dir proto from src to dst [options].

Action (DiameterQosAction): Defines the operation for the packet, e.g., tagging or metering.

Actions:

• tag: Mark packets with a DSCP value.

• meter: Apply rate-based traffic metering.

Direction (DiameterRuleDirection): Packet direction:

• in: Incoming traffic.

• out: Outgoing traffic.

Protocol (InternetProtocol): Transport protocol, e.g., TCP, UDP, or ICMP.

Source Address (DiameterRuleAddress): Source IP address or range.

Source Ports (List<DiameterRulePorts>): Source port(s) or port range(s).

Destination Address (DiameterRuleAddress): Destination IP address or range.

Destination Ports (List<DiameterRulePorts>): Destination port(s) or port range(s).

DSCP Color (String): DSCP value for marking packets, defined in [RFC 2474].

Metering Rate (Long): Throughput rate in bits per second.

Color Under (String): DSCP value for packets under the rate limit, per [RFC 2597].

Color Over (String): DSCP value or drop for packets exceeding the rate limit, per [RFC 3246].

Usage Rules:

• Tagging (Action = Tag): DSCP value (DSCP <color>) must be specified.

• Metering (Action = Meter): Must include rate, color_under, and color_over.

• Rule Evaluation: Rules are evaluated in order. The first matching rule terminates evaluation.

• Default Behavior: If no rules match, packets are treated as best-effort.

• NAS Constraints: If the NAS cannot apply the rules, the session should not be terminated.

Filter-Id

11

UTF8String

IETF

Specifies the name of a filter list associated with a user. It is primarily used for authorization purposes and enables NAS devices to enforce user-specific filtering rules. The filter list name is intended to be human-readable and allows for portability across different NAS implementations without requiring details about the underlying implementation of the filter list. However, the Filter-Id AVP is not ideal for roaming scenarios since filter names can vary across service providers.

Usage Rules:

• Zero or more Filter-Id AVPs may be included in an authorization answer message.

• The AVP is designed for compatibility with RADIUS environments but may not work well in roaming scenarios.

• In non-RADIUS environments, the NAS-Filter-Rule AVP (Section 4.4.6) [RFC 7155] is recommended for defining filter rules.

Framed-Appletalk-Link

37

Unsigned32

IETF

Specifies the AppleTalk network number to be used for a serial link connecting the NAS (Network Access Server) and the user. This AVP is intended for use when the user is an AppleTalk router, and it facilitates the configuration of the network number for the link. The AVP is included only in authorization responses and is not applicable for non-router users.

Value Range:

0: Indicates an unnumbered serial link.

1 to 65,535: Assigns the specified number as the AppleTalk network number for the serial link.

Usage Rules:

• This AVP must appear only in an authorization response.

• It must not be included for non-router users.

• This AVP applies only to configurations involving AppleTalk networks.

Framed-Appletalk-Network

38

Unsigned32

IETF

Specifies the AppleTalk network number that the NAS (Network Access Server) should probe to allocate an AppleTalk node for the user. This AVP is intended for use when the user is another AppleTalk router and provides guidance for configuring the user's AppleTalk network.

Value Range:

• 0: Indicates that the NAS should assign a network using its default cable range.

• 1 to 65,535: Specifies that the NAS should probe the given AppleTalk network number to allocate an address for the user.

Usage Rules:

• The AVP must be present only in an authorization response.

• It is not applicable for non-router users.

• If multiple Framed-Appletalk-Network AVPs are included in a response, the NAS may use any of the provided network numbers to probe and allocate the address.

• The AVP applies only in configurations involving AppleTalk networks.

Framed-Appletalk-Zone

39

OctetString

IETF

Specifies the AppleTalk Default Zone to be assigned to a user session. It defines the logical grouping of AppleTalk nodes and ensures proper network routing and resource sharing within that zone.

Usage Rules:

• This AVP must appear only in an authorization response message.

• Only one instance of the Framed-Appletalk-Zone AVP is allowed in the same message. Multiple instances are invalid and must not be included.

• The format and allowed range for the zone value are not defined within this specification. Implementation-specific rules apply.

Framed-Compression

13

Enumerated

IETF

The Framed-Compression AVP specifies the compression protocol to be used for the link. It helps optimize data transmission efficiency by reducing the size of transmitted data.

Enumerated Values

0 None: No compression protocol is applied.

1 VJ TCP/IP Header: Van Jacobson TCP/IP header compression, as defined in RFC 1144.

2 IPX Header: IPX header compression for Novell networks.

3 Stac LZS: Stac LZS compression algorithm, used for high-performance data compression.

Recommendations:

• Provide multiple compression options to support flexible negotiation between NAS and server.

• Include None (0) as a fallback option to avoid failures if compression is unsupported.

Framed-Interface-Id

96

Unsigned64

IETF

Specifies the IPv6 interface identifier to be assigned to the user for network access. It MAY be used in authorization requests as a hint to the server that a specific interface identifier is desired, but the server is not required to honor the hint in the corresponding response. Ensure compatibility with [RFC 3315] (DHCPv6) or IPv6 Neighbor Discovery Protocol when configuring interface IDs.

Framed-IP-Address

8

IPv4 Address

IETF

Specifies the IPv4 address assigned to a user. It is primarily used during authentication and authorization to configure network access. This AVP may serve as a hint to request a specific IP address, but the server is not required to honor the request.

Special Values:

0xFFFFFFFF: Indicates that the user is allowed to select an IPv4 address (e.g., negotiated by the client device).

0xFFFFFFFE: Indicates that the NAS should select an IPv4 address for the user (e.g., from a predefined pool of IP addresses).

Framed-IP-Netmask

9

OctetString (IPv4 Netmask)

IETF

Specifies the IPv4 subnet mask for a user, particularly when the user acts as a router to a network. It can be used as a hint in authorization requests, but servers are not obligated to honor the specified value in the response.

Special Values

0xFFFFFFFF: Signals that the server must return a value for the netmask in the response.

Framed-IPv6-Pool

100

OctetString

IETF

Specifies the name of a pool that should be used to assign an IPv6 prefix for a user session. This AVP allows dynamic assignment of IPv6 prefixes from pre-defined pools, enabling flexible IP address management in NAS environments.

If the access device (NAS) does not support multiple IPv6 prefix pools, it must ignore this AVP. Although specified as OctetString, it is recommended to encode the data as UTF8String for interoperability. Complies to [RFC 3162] for compatibility with RADIUS.

Framed-IPv6-Prefix

97

OctetString

Used to specify the IPv6 prefix to be assigned to a user. It can be included in authorization requests as a hint for desired prefixes, but the server is not obligated to comply with the request in the response.

Recommendations:

• Ensure the provided prefix format conforms to CIDR notation (e.g., 2001:db8::/64).

• Use Framed-IPv6-Pool AVP as a backup in case no explicit prefix is assigned.

• Utilize INTERIM-RECORD updates to modify prefixes dynamically during sessions.

• Validate prefix length (typically /64 for SLAAC and /48 for routed prefixes).

Framed-IPv6-Route

99

UTF8String

IETF

Used to define IPv6 routing information that should be configured for the user on the NAS (Network Access Server). Multiple instances of this AVP can be included in an authorization response to specify multiple routes. The AVP value must use the US-ASCII character set for compatibility.

Structure:

The value of the AVP must conform to the following format:

IPv6 Prefix: An IPv6 address prefix followed by a / and a decimal number indicating the prefix length (number of significant bits).

Example: 2001:db8::/32

Gateway Address: The IPv6 gateway address in hexadecimal notation, separated by a space.

Example: 2001:db8:106:a00:20ff:fe99:a998

If the gateway address is the unspecified IPv6 address (::), the user's IPv6 address should be used as the gateway.

Metric(s): One or more routing metrics separated by spaces, indicating the priority or cost of the route.

Complete Example: "2001:db8::/32 2001:db8:106:a00:20ff:fe99:a998 1"

Framed-IPX-Network

23

Unsigned32

IETF

Used to specify an IPX (Internetwork Packet Exchange) network number for a user session. It    MAY be used in an authorization request as a hint to the server that a specific address is desired, but the server is not required to honor the hint in the corresponding response.

Special Values:

0xFFFFFFFF: Allows the user to select their own IPX address (Negotiated).

0xFFFFFFFE: The NAS dynamically selects an address for the user from a pre-configured address pool.

Framed-MTU

12

Unsigned32

IETF

Specifies the Maximum Transmission Unit (MTU) to be configured for a user session. It defines the largest size (in bytes) of a packet or frame that can be sent over the connection without fragmentation. This AVP should only be present in authorization responses. The MTU value must be in the range from 64 to 65535.

Framed-Pool

88

OctetString

IETF

Specifies the name of an address pool that should be used to assign an address for a user session. It is primarily used for IP address allocation, but it can also support other protocols if the Network Access Server (NAS) has the capability to handle address pools for them. If not provided, the NAS assigns an address based on its internal configuration. If multiple pools are unsupported, the NAS ignores this AVP. Although specified as type OctetString for compatibility with RADIUS [RFC 2869], the encoding of the Data field should also conform to the rules for the UTF8String Data Format.

Framed-Protocol

7

Enumerated

IETF

Defines the framing method to be used for framed access in a Diameter session. It can be included in both requests and responses to specify or negotiate the framing type. If omitted, the NAS determines the protocol based on its settings.

Enumerated Values

1 PPP: Point-to-Point Protocol. Widely used for dial-up and broadband connections.

2 SLIP: Serial Line Internet Protocol. Legacy protocol used for serial connections.

3 ARAP: AppleTalk Remote Access Protocol for AppleTalk networks.

4 Gandalf-SLMLP: Gandalf Single Line MultiLink Protocol.

5 X.75: ITU-T X.75 protocol for inter-network communication between ISDN systems.

6 Ethernet: Ethernet encapsulation for LAN access.

7 X.25: Packet-switched network protocol often used in legacy data communication.

8 Frame-Relay: Protocol for WAN communication using virtual circuits.

9 ATM: Asynchronous Transfer Mode for high-speed data transfer.

10 HDLC: High-Level Data Link Control protocol, often used in ISDN and leased lines.

Framed-Route

22

UTF8String

IETF

Specifies IPv4 routing information in US-ASCII format that is to be configured on the NAS for the user session. This AVP provides details about the destination prefix, gateway, and routing metrics. Zero or more Framed-Route AVPs may be included in an authorization response. The AVP value must be encoded in 7-bit US-ASCII format.

Structure:

The value of the AVP must conform to the following format:

Destination Prefix: IPv4 address in dotted quad format.

Optionally followed by a / and a prefix length in decimal specifying the number of high-order bits in the prefix.

If the prefix length is omitted, default values apply based on the class of the prefix:

• Class A: Default prefix length is 8 bits.

• Class B: Default prefix length is 16 bits.

• Class C: Default prefix length is 24 bits.

Example: 192.0.2.0/24 or 192.0.2.0.

Gateway Address: IPv4 address in dotted quad format.

If set to 0.0.0.0, the user's IP address is used as the gateway.

Example: 192.0.2.1 or 0.0.0.0.

Routing Metrics: One or more metric values separated by spaces, indicating the priority or cost of the route.

Example: 1.

Framed-Routing

10

Enumerated

IETF

Defines the routing method for a user when the user operates as a router connected to a network. It specifies whether the user should send, listen, or send and listen for routing updates and packets. This AVP should only be present in authorization responses.

Enumerated Values

0 (NONE): The user does not perform any routing operations.

1 (SEND): The user sends routing updates but does not listen for them.

2 (LISTEN): The user listens for routing updates but does not send them.

3 (SEND_AND_LISTEN): The user both sends and listens for routing updates.

Idle-Timeout

28

Unsigned32

IETF

Specifies the maximum duration, in seconds, that a user's connection can remain idle before taking an action, such as:

• Termination of the session.

• Issuing a prompt to the user.

If not explicitly set, the behavior defaults to the system's specific configuration.

Usage Rules:

• If the AVP is not provided, the system's default idle timeout applies.

• The system or NAS may terminate the session or prompt the user to remain active if the idle duration exceeds the specified timeout value.

• This AVP is typically used in scenarios where idle time needs to be monitored and managed, such as in AAA (Authentication, Authorization, and Accounting) frameworks.

• The AVP value must be an unsigned 32-bit integer. Represents time in seconds.

Login-IP-Host

14

OctetString (IPv4 Address)

IETF

Provides the IPv4 address of a host that the user should be connected to when the Login-Service AVP is included. It is primarily used to guide the Network Access Server (NAS) or Diameter server in establishing a connection with a specific host.

This AVP can be used:

• In AA-Request messages as a hint to the Diameter server about the preferred host.

• In AA-Answer messages to specify the host selected by the Diameter server.

Special Address Values:

• All Ones (255.255.255.255): Indicates that the NAS should allow the user to select a host address.

• Zero (0.0.0.0): Indicates that the NAS should select the host address.

It may be used in an AA-Request command as a hint to the Diameter server that a specific host is desired, but the Diameter server is not required to honor the hint in the AA-Answer.

Login-IPv6-Host

98

IPv6 Address

IETF

The Login-IPv6-Host AVP is used to specify the IPv6 address of a host to connect the user to when the Login-Service AVP is included. This AVP allows the NAS or Diameter server to handle IPv6-based connections for user sessions.

Special Address Values:

0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF: Indicates that the NAS should allow the user to choose an IPv6 address for the connection.

0:0:0:0:0:0:0:0 (represented as ::): Indicates that the NAS should select the host address automatically.

It may be used in an AA-Request command as a hint to the Diameter server that a specific host is desired, but the Diameter server is not required to honor the hint in the AA-Answer.

Login-LAT-Group

36

OctetString

IETF

Specifies the LAT group codes a user is authorized to use in LAT (Local Area Transport) protocol environments. LAT group codes act as access rights, defining which LAT services the user can connect to. Only valid when Login-Service-Type AVP is set to LAT.

 If not provided, users may not have access to LAT services. This AVP can be included in an authorization request as a hint for a desired group, but the Diameter server is not required to honor this hint in its response.

Bitmap Encoding

LAT supports 256 group codes.

Each bit in the 256-bit bitmap represents one group code:

1 = Authorized

0 = Not Authorized

Administrators assign the bitmap of authorized group codes to each user. The LAT service provider evaluates the group codes during connections to determine access rights.

Login-LAT-Node

35

OctetString

IETF

Specifies the LAT (Local Area Transport) node to which the user should be automatically connected. It contains a string identifying the LAT service or node. This AVP is used to guide the authorization and connection process for LAT-based services.

Usage Rules:

• Authorization Requests: The Login-LAT-Node AVP may be included in an AA-Request as a hint to the Diameter server, indicating the desired LAT node for the user. The server is not obligated to honor the hint in the response.

• Authorization Responses: The AVP must only appear in a response if the Login-Service-Type AVP is set to LAT.

• LAT Node String Field: The string field contains the identity of the LAT service or node to use. All string comparisons for LAT nodes are case insensitive. 

The LAT architecture supports the following characters in the string:

$ (dollar)

- (hyphen)

. (period)

_ (underscore)

Numbers

Uppercase and lowercase alphabetic characters

ISO Latin-1 character set extension [ISO.8859-1.1987]

Login-LAT-Port

63

OctetString

IETF

The Login-LAT-Port AVP specifies the port to which the user should be connected via the Local Area Transport (LAT) protocol. This AVP is used to guide the authorization process and direct the connection to a specific LAT port. 

Usage Rules:

• Authorization Requests: The Login-LAT-Port AVP may be included in an AA-Request as a hint to the Diameter server, indicating the desired LAT port for the user. The server is not obligated to honor this hint in its response.

• Authorization Responses: This AVP must only appear in a response if the Login-Service-Type AVP is set to LAT.

• String Field Characteristics: LAT string comparisons for ports are case insensitive. The LAT architecture supports the following characters in the string:

$ (dollar)

- (hyphen)

. (period)

_ (underscore)

Numbers

Uppercase and lowercase alphabetic characters

ISO Latin-1 character set extension [ISO.8859-1.1987]

Login-LAT-Service

34

OctetString

IETF

Specifies the LAT (Local Area Transport) service to which the user is connected. It is used to define the system or service name associated with the LAT connection.

Authorization Request: It can be included as a hint for a desired LAT service in authorization requests, but the server is not required to honor the hint in the corresponding response.

Authorization Response: It is mandatory in the response if the Login-Service AVP specifies LAT as the service type.

String Format: LAT string comparisons are not case-sensitive. Allowed characters in the string:

• Alphanumeric (A-Z, a-z, 0-9)

• Special symbols: $, -, ., _

• Character Encoding:

• Supports ISO Latin-1 character set [ISO.8859-1.1987].

Login-Service

15

Enumerated

IETF

Specifies the type of service used to connect a user to the login host. It defines the connection method and protocols supported for remote login access.

This AVP is optional in authorization responses and not used in requests.

Enumerated Values (Defaults to 0 TELNET if unspecified):

0 TELNET: Connects the user via TELNET protocol.

1 RLOGIN: Uses Remote Login (RLOGIN) for shell access.

2 TCP_CLEAR: Provides TCP clear-text connections without encryption.

3 PORT_MASTER: Connects via a port master protocol.

4 LAT: Establishes Local Area Transport (LAT) sessions.

5 X25_PAD: Connects through X.25 PAD (Packet Assembler/Disassembler) service.

6 X25_T3POS: Uses X.25 T3POS (Point-to-Point protocol) service.

7 TCP_CLEAR_QUIET: Similar to TCP_CLEAR but avoids sending banner messages.

Login-TCP-Port

16

Unsigned32

IETF

Specifies the TCP port number for connecting a user to a remote service, such as TELNET or RLOGIN, as defined by the Login-Service AVP. The value must be a valid TCP port number between 0 and 65535. This AVP is included in authorization responses and not in requests.

NAS-Filter-Rule

400

IPFilterRule

IETF

Defines filter rules that need to be applied by the NAS (Network Access Server) for a specific user session. It allows administrators to specify traffic filtering policies for authorized users. This AVP is typically included in authorization responses and is used to enforce security and access control policies. Multiple AVPs can be included to define complex filtering rules.

Filter Rule Format:
Rules follow the syntax defined in [RFC 6733], based on FreeBSD’s ipfw(8) rule syntax.

Format: action dir proto from src to dst [options]

action: Specifies the action (permit/deny).

dir: Traffic direction (in or out).

proto: Protocol (e.g., tcp, udp, icmp).

src/dst: Source/Destination IP addresses, optionally masked.

options: Additional filtering parameters, such as ports, DSCP, etc.

NAS-Identifier

32

UTF8String

IETF

Provides the identity of the NAS (Network Access Server) that is delivering services to the user. Typically, this AVP is included in Diameter messages by a RADIUS/Diameter translation agent, and it complements the information provided in the Origin-Host AVP. It is designed for environments where the NAS identity is critical for authentication, authorization, or accounting processes.

Usage Rules:

The NAS-Identifier AVP should only be added by a RADIUS/Diameter translation agent.

When present, it identifies the NAS providing the service, and the Origin-Host AVP provides additional context.

Validation:

Diameter Agents/Servers: Should validate that the NAS-Identifier matches an entry in the Route-Record AVP. If no match is found, an error is logged, but no immediate corrective action is taken.

RADIUS/Diameter Translation Agents: Must attempt to verify the NAS-Identifier by performing a DNS A/AAAA RR query if the identifier contains an FQDN. If the DNS resolution fails, the agent should log an error and attempt a reverse lookup on the source IP address, using the resulting FQDN to populate the Route-Record AVP.

RADIUS Compatibility: While RADIUS allows the NAS-Identifier to contain any UTF8 string, there is a risk of forgery by rogue NAS devices. Diameter introduces stricter validation by leveraging DNS lookups and Route-Record checks to enhance security.

NAS-IP-Address

4

Ipv4Address

IETF

Provides the IPv4 address of the NAS (Network Access Server) providing the service to the user. It serves as an identifier for the NAS in Diameter-based authentication, authorization, and accounting (AAA) systems. 

NAS-IPv6-Address

95

OctetString (IPv6 Address)

IETF

Used to specify the IPv6 address of the NAS (Network Access Server) providing service to a user. It plays a critical role in identification, authorization, and accounting within Diameter and RADIUS protocols, especially in modern IPv6-enabled networks.

NAS-Port 

5

Unsigned32

IETF

Identifies the physical or virtual port number of the NAS (Network Access Server) that authenticated the user. Note that "port" is meant in its sense as a service connection on the NAS, not as an IP protocol identifier; hence, the format and contents of the string that identifies the port are specific to the NAS implementation.

NAS-Port-Id

87

AsciiString

IETF

Provides a textual identifier for the port of the NAS (Network Access Server) that is authenticating the user. Unlike the NAS-Port AVP, which uses a numeric representation, the NAS-Port-Id AVP allows for a more descriptive and flexible textual identifier. This is particularly useful for NAS devices that do not conveniently number their ports or require more detailed identification. The value of the AVP must conform to 7-bit US-ASCII text encoding, allowing for human-readable identifiers. The AVP value may include identifiers such as port descriptions or physical location details. Usage Rules:

• The NAS-Port-Id AVP should be included in an AA-Request (AAR) command when the NAS differentiates among its ports.

• It can serve as an alternative to the NAS-Port AVP for identifying the service connection.

NAS-Port-Type

61

Enumerated

IETF

Specifies the type of port used by the Network Access Server (NAS) for user authentication. It is particularly useful when a NAS uses the same NAS-Port number ranges for different service types at the same time. This AVP allows administrators to distinguish between different port types and ensure that policies can be applied based on the port's capabilities or service type.

Enumerated Values

0 - ASYNC: Asynchronous serial port.

1 - SYNC: Synchronous serial port.

2 - ISDN_SYNC: ISDN (Integrated Services Digital Network) synchronous.

3 - ISDN_ASYNC_V120: ISDN asynchronous V.120.

4 - ISDN_ASYNC_V110: ISDN asynchronous V.110.

5 - VIRTUAL: Virtual port.

6 - PIAFS: PIAFS (Personal Handyphone System Internet Access Forum).

7 - HDLC_CLEAR_CHANNEL: HDLC clear channel.

8 - X_25: X.25 packet-switched network.

9 - X_75: X.75 protocol.

10 - G3_FAX: Group 3 Fax.

11 - SDSL: Symmetric DSL (Digital Subscriber Line).

12 - ADSL_CAP: Asymmetric DSL, Carrierless Amplitude Phase Modulation (CAP).

13 - ADSL_DMT: Asymmetric DSL, Discrete Multi-Tone (DMT).

14 - IDSL_ISDN: IDSL over ISDN.

15 - ETHERNET: Ethernet port.

16 - XDSL: Generic xDSL technologies.

17 - CABLE: Cable modem connection.

18 - WIRELESS_OTHER: Wireless connections (other types).

19 - WIRELESS_IEEE_802_11: Wireless LAN based on IEEE 802.11 (Wi-Fi).

20 - TOKEN_RING: Token Ring network.

21 - FDDI: Fiber Distributed Data Interface.

22 - WIRELESS_CDMA2000: Wireless CDMA2000 connection.

23 - WIRELESS_UMTS: Wireless UMTS (3G) connection.

24 - WIRELESS_UMTS_1X_EV: Wireless UMTS 1xEV connection.

25 - IAPP: Inter Access Point Protocol (IAPP).

26 - FTTP: Fiber to the Premises (FTTP).

27 - WIRELESS_IEEE_802_16: Wireless MAN based on IEEE 802.16 (WiMAX).

28 - WIRELESS_IEEE_802_20: Wireless MAN based on IEEE 802.20.

29 - WIRELESS_IEEE_802_22: Wireless MAN based on IEEE 802.22.

30 - PPPoA: Point-to-Point Protocol over ATM.

31 - PPPoEoA: Point-to-Point Protocol over Ethernet over ATM.

32 - PPPoEoE: Point-to-Point Protocol over Ethernet over Ethernet.

33 - PPPoEoVLAN: Point-to-Point Protocol over Ethernet over VLAN.

34 - PPPoEoQinQ: Point-to-Point Protocol over Ethernet over QinQ VLAN tagging.

35 - XPON: Passive Optical Network.

36 - WIRELESS_XGP: Wireless XGP technology.

37 - WiMAX_PRE_RELEASE_8: Pre-release WiMAX version 8.

38 - WiMAX_WIFI_IWK: WiMAX and Wi-Fi interworking connection.

39 - WiMAX_SFF: WiMAX Self-Forming and Self-Healing networks.

40 - WiMAX_HA_LMA: WiMAX Home Agent and Local Mobility Anchor integration.

41 - WiMAX_DHCP: WiMAX with DHCP-based address assignment.

42 - WiMAX_LBS: WiMAX with Location-Based Services.

43 - WiMAX_WVS: WiMAX with Wireless Virtual Switch capabilities.

Origin-AAA-Protocol 

408

Enumerated

IETF

Identifies the source protocol of a message that has been translated by a gateway system into a Diameter message. This AVP is particularly useful when messages are converted from legacy AAA protocols, such as RADIUS, into Diameter for interoperability and compatibility purposes.

Enumerated Values:

1 - RADIUS: Message was translated from the RADIUS protocol.

Originating-Line-Info

94

OctetString

IETF

Conveys information about the origin of a call based on details provided by the Signaling System 7 (SS7) network. This AVP is typically sent by the NAS system and includes the Originating Line Information (OLI) element, which describes the characteristics or nature of the line from which the call originated (e.g., pay phone, cellular phone, hotel phone). Internet Service Providers (ISPs) and telecommunication providers can utilize this AVP in conjunction with Called-Station-Id and Calling-Station-Id AVPs to distinguish customer calls and define different service levels or policies.

Value Format:

The AVP Value contains two octets (00–99).

The specific values and their meanings align with ANSI T1.113, BELLCORE 394, and other SS7 standards.

ISPs and service providers can use this AVP to differentiate between calls originating from various line types, such as:

• Payphones

• Hotel phones

• Cellular phones

• Other public or private networks

Password-Retry

75

Unsigned32

IETF

Used to define the number of authentication attempts allowed before a user is disconnected. This AVP is typically included in an AA-Answer (AAA) message when the Result-Code indicates an authentication failure. It is primarily designed for use when the Framed-Protocol AVP is set to ARAP (AppleTalk Remote Access Protocol).

Port-Limit

62

Unsigned32

IETF

Specifies the maximum number of ports that a NAS (Network Access Server) can provide to a user. This AVP may be included in authentication and/or authorization requests as a hint that the user desires multilink PPP (Point-to-Point Protocol) service, as defined in [RFC 1990]. However, the Diameter server is not obligated to honor this request in its response.

Prompt

76

Enumerated

IETF

Used to specify whether a user’s response should be echoed when entered. It is typically included in an AA-Answer (AAA) message. The AVP allows the NAS to determine if user input should be visible (echoed) or hidden (not echoed).

Enumerated Values:

0 - NO_ECHO: The user's input should not be echoed (e.g., for passwords).

1 - ECHO: The user's input should be echoed (e.g., for non-sensitive data).

Reply-Message

18

UTF8String

IETF

Intended to convey information to the user. It is typically included in AA-Answer or Re-Auth-Request messages to provide feedback, prompt for further action, or display success or failure messages. The content of the Reply-Message AVP is implementation-specific and depends on the use case.

Usage Scenarios:

• When included in an AA-Answer message with a Result-Code set to DIAMETER_SUCCESS, the Reply-Message AVP may include a success message to inform the user.

• When included in a message with a Result-Code other than DIAMETER_SUCCESS, it contains a failure message explaining why the operation failed.

• When included in an AA-Answer with Result-Code set to DIAMETER_MULTI_ROUND_AUTH, it can prompt the user for additional input required for subsequent AA-Request attempts.

• In a Re-Auth-Request message, the AVP may include text prompting the user for specific actions or responses required for session continuation.

Service-Type

6

Enumerated

IETF

Specifies the type of service the user has requested or the type of service to be provided by the NAS (Network Access Server). It can appear in authentication or authorization requests or responses and provides a hint to the server about the user's service preferences. However, the server is not obligated to honor the requested service type.

If the NAS receives an unknown or unsupported Service-Type AVP in a response, it must treat it as an error and terminate the session with the DIAMETER_INVALID_AVP_VALUE Result-Code.

Enumerated Values:

Login (1): The user is connected to a host. Additional AVPs (e.g., related to login parameters) may be included, such as Login-LAT-Service, Login-LAT-Group, etc.

Framed (2): A framed protocol like PPP or SLIP is initiated for the user. Additional AVPs for tunneling services, such as Framed-IP-Address or Framed-Route, may be included.

Callback Login (3): The user is disconnected and then called back to establish a host connection. Relevant callback parameters may be included.

Callback Framed (4): The user is disconnected and called back to start a framed protocol like PPP or SLIP. Additional AVPs for tunneling services may apply.

State

24

OctetString

IETF

Serves as a mechanism for maintaining state information between a Diameter Server and a NAS. The State AVP provides a way for the server to maintain state information for a session without requiring the NAS to interpret it. This AVP has two main purposes:

• In Multi-Round Authentication: The State AVP may be sent by the Diameter Server in an AA-Response command that contains a Result-Code of DIAMETER_MULTI_ROUND_AUTH. The NAS must include the State AVP unmodified in its subsequent AA-Request command.

• In Termination-Action Handling: The State AVP may be included in an AA-Response command along with a Termination-Action AVP set to AA-REQUEST. If the NAS performs the specified Termination-Action by sending a new AA-Request upon termination of the current service, it must include the State AVP unmodified in the new request.

Tunnel-Assignment-Id

82

OctetString

IETF

Used to indicate to the tunnel initiator the specific tunnel to which a session is to be assigned. This AVP is applicable for scenarios involving tunneling protocols, such as PPTP [RFC 2637] and L2TP [RFC 3931], where multiple sessions can either share a single multiplexed tunnel or be assigned to dedicated tunnels. 

This AVP enables Diameter servers to guide the tunnel initiator (e.g., a LAC) in assigning sessions to appropriate tunnels, potentially enabling differentiated levels of service for specific sessions or groups of sessions.

Behavior and Usage:

The AVP specifies a tunnel ID that the tunnel initiator should use to assign the session to an existing or new tunnel:

• If a tunnel with the specified ID exists, the session is assigned to it.

• If no such tunnel exists, a new tunnel is created using the specified ID.

• If the AVP is absent, the session is assigned to an unnamed tunnel.

Sessions sharing a multiplexed tunnel can be grouped under the same Tunnel-Assignment-Id. Separate Tunnel-Assignment-Id values can be used to segment sessions across different multiplexed tunnels for optimized management or differentiated QoS.

The AVP allows sessions to be assigned to tunnels with specific QoS parameters or other characteristics. These characteristics can be configured locally on the tunnel initiator.

This AVP should be included in Accounting-Request messages for tunneled sessions to track tunnel assignments.

Tunnel initiators that support this AVP should:

• Honor the Tunnel-Assignment-Id if provided.

• Ignore the AVP if they do not support its usage and handle tunnel assignment arbitrarily.

The Tunnel-Assignment-Id is of significance only to the Diameter server and the tunnel initiator. The ID is not conveyed to the tunnel peer and is used solely for local identification and management.

Tunnel-Client-Auth-Id

90

UTF8String

IETF

Used to specify the 7-bit US-ASCII name that a tunnel initiator uses during the authentication phase of tunnel establishment. This AVP provides the necessary credentials or identifiers for establishing a secure and authenticated tunnel session.

Behavior and Usage:

• The AVP may be included in an authorization request to indicate a preference for a specific authentication identifier to be used during the tunnel establishment process. The server is not required to honor this preference in its response.

• If a specific authentication identifier, other than the default, is required for the session, the AVP must be included in the authorization response by the server.

• The AVP should be included in Accounting-Request (ACR) messages for sessions that use tunnels, ensuring traceability and consistency across tunneled sessions.

• The format and validation of the Tunnel-Client-Auth-Id are left to local configuration and depend on the requirements of the tunnel initiator and Diameter server.

• If the AVP is absent or not supported, the tunnel initiator may fall back to using a default authentication identifier.

Tunnel-Client-Endpoint

66

UTF8String

IETF

Contains the address of the initiator end of the tunnel. It serves as a unique identifier for the client-side of the tunnel connection. 

Behavior and Usage:

• Authorization Request: The Tunnel-Client-Endpoint AVP may be included to specify a desired client endpoint for tunnel initiation. The server is not required to honor the requested endpoint in its response.

• Accounting Requests: This AVP should be included in Accounting-Request (ACR) messages to log the address from which the tunnel was initiated.

• Unique Tunnel Identification: When combined with the Tunnel-Server-Endpoint AVP and Session-Id AVP, it provides a globally unique means of identifying a tunnel for accounting and auditing purposes.

Value Based on Tunnel-Medium-Type AVP: 

IPv4 (1): The value is either:

• A fully qualified domain name (FQDN) of the client machine.

• A "dotted-decimal" IP address (e.g., 192.168.1.1).

IPv6 (2): The value is either:

• An FQDN of the client machine.

• A text representation of the IPv6 address in preferred or alternate forms as per [RFC3516].

Other Medium Types: The value is a tag referring to local configuration data on the Diameter client that describes the medium-specific client address or interface.

Internationalized Domain Names (IDNs): Handled as per the Diameter Base Protocol (Appendix D of [RFC 6733]).

Tunneling

401

Grouped

IETF

Defines the parameters required to establish and configure a compulsory tunnel service. It supports various tunneling protocols, including PPTP and L2TP, as described in [RFC 2867] and [RFC 2868]. It combines multiple sub-AVPs to describe the tunnel type, medium type, client and server endpoints, preferences, and authentication details. This AVP is primarily used for authorization and accounting in Diameter-based networks.

The AVP structure is defined as follows:

Tunnel-Type (64, Enumerated): Specifies the tunnel protocol type (e.g., PPTP, L2TP).

Tunnel-Medium-Type (65, Enumerated): Indicates the medium type (e.g., IPv4, IPv6).

Tunnel-Client-Endpoint (66, UTF8String): Defines the address or endpoint of the client side of the tunnel.

Tunnel-Server-Endpoint (67, UTF8String): Defines the address or endpoint of the server side of the tunnel.

Tunnel-Preference (83, Unsigned32): Specifies preferences for tunnel selection (optional).

Tunnel-Client-Auth-Id (90, UTF8String): Specifies the authentication ID used by the client for tunnel establishment.

Tunnel-Server-Auth-Id (91, UTF8String): Specifies the authentication ID used by the server for tunnel establishment.

Tunnel-Assignment-Id (82, OctetString): Provides an identifier for assigning a session to a specific tunnel.

Tunnel-Password (69, OctetString): Contains a password used for authentication during tunnel setup.

Tunnel-Private-Group-Id (81, OctetString): Defines a group identifier for private tunneling.

Tunnel-Medium-Type

65

Enumerated

IETF

Specifies the transport medium to be used when creating a tunnel for protocols like L2TP (Layer 2 Tunneling Protocol). It is primarily intended for authorization requests and acts as a hint for the server regarding the desired transport medium. However, the server is not required to honor this preference. If this AVP is absent, the server assigns a default transport medium based on local policies.

Enumerated Values

1 - IPv4: Specifies IPv4 as the transport medium.

2 - IPv6: Specifies IPv6 as the transport medium.

3 - NSAP: Network Service Access Point.

4 - HDLC: High-Level Data Link Control.

5 - BBN_1822: Legacy protocol defined by BBN for ARPANET.

6 - M802: IEEE 802 media types, like Ethernet or Wi-Fi.

7 - E_163: ITU E.163 numbering plan for telephone networks.

8 - E_164: ITU E.164 numbering plan for telephony.

9 - F_69: ITU F.69 numbering plan for telegraph services.

10 - X_121: ITU-T X.121 addressing for X.25 networks.

11 - IPX: Novell IPX protocol for local area networks.

12 - APPLETALK: AppleTalk protocol for Apple devices.

13 - Decnet_IV: DECnet Phase IV networking protocol.

14 - BANYAN: Banyan VINES networking protocol.

15 - E_164_WITH_NSAP: Combined ITU E.164 and NSAP addressing.

Tunnel-Password

69

OctetString

IETF

Used to store a password for authentication to a remote server during tunnel establishment. The Tunnel-Password AVP should NOT be used in untrusted proxy environments without encrypting it by using end-to-end security techniques.

Tunnel-Preference

83

Unsigned32

IETF

Identifies the relative preference assigned to each tunnel when multiple sets of tunneling AVPs are returned in separate grouped AVPs. It enables the tunnel initiator to prioritize between available tunneling options. The Tunnel-Preference AVP may be included to indicate a preferred priority for tunnel selection, however the server is not required to honor the specified preference in its response.

If tunnels are assigned identical Tunnel-Preference values, the tunnel initiator should rely on local metrics for the final selection.

Preference Ranking: A lower numerical value in the Tunnel-Preference AVP indicates higher priority. The tunnel initiator selects the tunnel configuration with the lowest value among all Tunnel-Preference AVPs. If two or more Tunnel-Preference AVPs have identical values, the initiator should use local metrics or policies to decide the preferred tunnel.

Example Use Case:

A Diameter server returns AVPs describing two tunnels:

Tunnel 1: PPTP, Tunnel-Preference = 10.

Tunnel 2: L2TP, Tunnel-Preference = 5.

The tunnel initiator selects the L2TP tunnel because it has the lower Tunnel-Preference value.

Tunnel-Private-Group-Id

81

OctetString

IETF

Used to identify a group ID for a particular tunneled session. This AVP helps associate tunneled sessions with specific private groups, facilitating network routing and other group-related policies.

The Tunnel-Private-Group-Id AVP may be included in the authorization request by the tunnel initiator if it can pre-determine the private group associated with the session.

The Tunnel-Private-Group-Id AVP should be included in the response if the tunnel session is associated with a specific private group.

It informs the tunnel initiator to treat the session as part of the designated private group.

This AVP should be included in the Accounting-Request (ACR) messages related to the tunneled session for logging purposes.

Tunnel-Server-Auth-Id

91

UTF8String

IETF

Identifies the 7-bit US-ASCII name used by the tunnel terminator during the authentication phase of tunnel establishment. This AVP helps configure specific authentication preferences for the tunnel endpoint.

This AVP may be included in the authorization request as a hint to the Diameter server indicating a specific preference for the server authentication ID. However the server is not required to honor this hint in the corresponding response.

The Tunnel-Server-Auth-Id AVP must be included in the authorization response if a non-default authentication name is desired for the tunnel terminator.

This AVP should be included in Accounting-Request (ACR) messages related to the tunneled session to log the authentication details.

Tunnel-Server-Endpoint

67

UTF8String

IETF

Specifies the address of the server end of the tunnel. It is primarily used for identifying the server endpoint in tunneling sessions and can assist in secure tunneling, session identification, and auditing. 

The AVP may be included in an authorization request as a hint to the Diameter server, indicating a desired specific tunnel server endpoint. However the Diameter server is not required to honor this hint in its response.

The AVP should be included in corresponding Accounting-Request (ACR) messages, where it indicates the address from which the tunnel was initiated.

Value Representation Based on Tunnel-Medium-Type AVP:

IPv4: The value is either a fully qualified domain name (FQDN) of the tunnel server or a "dotted-decimal" IPv4 address.

Requirements:

• MUST support the dotted-decimal format.

• SHOULD support the FQDN format.

IPv6: The value is either a FQDN or a textual IPv6 representation in the preferred or alternate form as defined in [RFC 3516].

Requirements:

• MUST support the preferred textual format.

• SHOULD support the alternate textual and FQDN formats.

Non-IPv4/IPv6 Mediums: The value is a tag that refers to configuration data local to the Diameter client, describing the interface or medium-specific server address to use.

Tunnel-Type

64

Enumerated

IETF

Specifies the tunneling protocol to be used (for a tunnel initiator) or that is currently in use (for a tunnel terminator). May be included in an authorization request to suggest a specific tunneling protocol to the Diameter server. The server is not required to honor the suggested tunnel type.

The Diameter server includes the Tunnel-Type AVP in its response to specify the type of tunnel to be used. If the tunnel initiator does not support the received tunnel type(s), it must treat the response as a failure.

Should be included in Accounting-Request (ACR) messages to indicate the type of tunnel being used.

Enumerated Values:

1: PPTP (Point-to-Point Tunneling Protocol)

2: L2F (Layer 2 Forwarding)

3: L2TP (Layer 2 Tunneling Protocol)

4: ATMP (Ascend Tunnel Management Protocol)

5: VTP (Virtual Tunneling Protocol)

6: AH (IP Authentication Header)

7: IP-IP (IP-in-IP Encapsulation)

8: MIN-IP-IP (Minimal IP-in-IP Encapsulation)

9: ESP (Encapsulating Security Payload)

10: GRE (Generic Routing Encapsulation)

11: DVS (Digital Video System)

12: IP-in-IP (Alternative IP Encapsulation)

13: VLAN (Virtual LAN)

User-Password

2

OctetString

IETF

Contains the user's password for authentication purposes or a user's input in a multi-round authentication exchange. This AVP represents sensitive information, as it holds a user password or one-time password.

The User-Password AVP is typically used in Diameter messages to authenticate a user.

Encryption Requirements:

MUST be encrypted using IPsec [RFC 4301] or Transport Layer Security (TLS) [RFC 5246] as mandated by the Diameter Base protocol [RFC 6733].

End-to-end security techniques should be applied, especially in untrusted proxy environments, to prevent exposure of sensitive information.

The clear-text password (before encryption) must not exceed 128 bytes in length.

When used for one-time passwords, this AVP is appropriate even in environments where permanent storage or trust is not guaranteed.