4.3.1. Common Derived AVP Data Formats
The following are commonly used Derived AVP Data Formats.
Address
The Address format is derived from the OctetString Basic AVP Format. It is a discriminated union representing, for example, a 32-bit (IPv4) [RFC0791] or 128-bit (IPv6) [RFC4291] address, most significant octet first. The first two octets of the Address AVP represent the AddressType, which contains an Address Family, defined in [IANAADFAM]. The AddressType is used to discriminate the content and format of the remaining octets.
Time
The Time format is derived from the OctetString Basic AVP Format. The string MUST contain four octets, in the same format as the first four bytes are in the NTP timestamp format. The NTP timestamp format is defined in Section 3 of [RFC5905].
This represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC).
On 6h 28m 16s UTC, 7 February 2036, the time value will overflow. Simple Network Time Protocol (SNTP) [RFC5905] describes a procedure to extend the time to 2104. This procedure MUST be supported by all Diameter nodes.
UTF8String
The UTF8String format is derived from the OctetString Basic AVP Format. This is a human-readable string represented using the ISO/IEC IS 10646-1 character set, encoded as an OctetString using the UTF-8 transformation format [RFC3629].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations MUST be prepared to encounter any code point from 0x00000001 to 0x7fffffff. Byte sequences that do not correspond to the valid encoding of a code point into UTF-8 charset or are outside this range are prohibited.
The use of control codes SHOULD be avoided. When it is necessary to represent a new line, the control code sequence CR LF SHOULD be used.
The use of leading or trailing white space SHOULD be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, MAY be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 charset is identical to the US-ASCII charset.
UTF-8 may require multiple bytes to represent a single character / code point; thus, the length of a UTF8String in octets may be different from the number of characters encoded.
Note that the AVP Length field of an UTF8String is measured in octets not characters.
DiameterIdentity
The DiameterIdentity format is derived from the OctetString Basic AVP Format.
DiameterIdentity = FQDN/Realm
The DiameterIdentity value is used to uniquely identify either:
-
A Diameter node for purposes of duplicate connection and routing loop detection.
-
A Realm to determine whether messages can be satisfied locally or whether they must be routed or redirected.
When a DiameterIdentity value is used to identify a Diameter node, the contents of the string MUST be the Fully Qualified Domain Name (FQDN) of the Diameter node. If multiple Diameter nodes run on the same host, each Diameter node MUST be assigned a unique DiameterIdentity. If a Diameter node can be identified by several FQDNs, a single FQDN should be picked at startup and used as the only DiameterIdentity for that node, whatever the connection on which it is sent. In this document, note that DiameterIdentity is in ASCII form in order to be compatible with existing DNS infrastructure. See Appendix D for interactions between the Diameter protocol and Internationalized Domain Names (IDNs).
DiameterURI
The DiameterURI MUST follow the Uniform Resource Identifiers (RFC3986) syntax [RFC3986] rules specified below:
"aaa://" FQDN [ port ] [ transport ] [ protocol ]
; No transport security
"aaas://" FQDN [ port ] [ transport ] [ protocol ]
; Transport security used
FQDN = < Fully Qualified Domain Name >
port = ":" 1*DIGIT
; One of the ports used to listen for
; incoming connections.
; If absent, the default Diameter port
; (3868) is assumed if no transport
; security is used and port 5658 when
; transport security (TLS/TCP and DTLS/SCTP)
; is used.
transport = ";transport=" transport-protocol
; One of the transports used to listen
; for incoming connections. If absent,
; the default protocol is assumed to be TCP.
; UDP MUST NOT be used when the aaa-protocol
; field is set to diameter.
transport-protocol = ( "tcp" / "sctp" / "udp" )
protocol = ";protocol=" aaa-protocol
; If absent, the default AAA protocol
; is Diameter.
aaa-protocol = ( "diameter" / "radius" / "tacacs+" )
The following are examples of valid Diameter host identities:
aaa://host.example.com;transport=tcp
aaa://host.example.com:6666;transport=tcp
aaa://host.example.com;protocol=diameter
aaa://host.example.com:6666;protocol=diameter
aaa://host.example.com:6666;transport=tcp;protocol=diameter
aaa://host.example.com:1813;transport=udp;protocol=radius
Enumerated
The Enumerated format is derived from the Integer32 Basic AVP Format. The definition contains a list of valid values and their interpretation and is described in the Diameter application introducing the AVP.
IPFilterRule
The IPFilterRule format is derived from the OctetString Basic AVP Format and uses the ASCII charset. The rule syntax is a modified subset of ipfw(8) from FreeBSD. Packets may be filtered based on the following information that is associated with it:
Direction (in or out)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
TCP flags
IP fragment flag
IP options
ICMP types
Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny.
IPFilterRule filters MUST follow the format:
action dir proto from src to dst [options]
action permit - Allow packets that match the rule.
deny - Drop packets that match the rule.
dir "in" is from the terminal, "out" is to the
terminal.
proto An IP protocol specified by number. The "ip"
keyword means any protocol will match.
src and dst <address/mask> [ports]
The <address/mask> may be specified as:
ipno An IPv4 or IPv6 number in dotted-
quad or canonical IPv6 form. Only
this exact IP number will match the
rule.
ipno/bits An IP number as above with a mask
width of the form 192.0.2.10/24. In
this case, all IP numbers from
192.0.2.0 to 192.0.2.255 will match.
The bit width MUST be valid for the
IP version, and the IP number MUST
NOT have bits set beyond the mask.
For a match to occur, the same IP
version must be present in the
packet that was used in describing
the IP address. To test for a
particular IP version, the bits part
can be set to zero. The keyword
"any" is 0.0.0.0/0 or the IPv6
equivalent. The keyword "assigned"
is the address or set of addresses
assigned to the terminal. For IPv4,
a typical first rule is often "deny
in ip! assigned".
The sense of the match can be inverted by
preceding an address with the not modifier (!),
causing all other addresses to be matched
instead. This does not affect the selection of
port numbers.
With the TCP, UDP, and SCTP protocols, optional
ports may be specified as:
{port/port-port}[,ports[,...]]
The '-' notation specifies a range of ports
(including boundaries).
Fragmented packets that have a non-zero offset
(i.e., not the first fragment) will never match
a rule that has one or more port
specifications. See the frag option for
details on matching fragmented packets.
options:
frag Match if the packet is a fragment and this is not
the first fragment of the datagram. frag may not
be used in conjunction with either tcpflags or
TCP/UDP port specifications.
ipoptions spec
Match if the IP header contains the comma-separated
list of options specified in spec. The
supported IP options are:
ssrr (strict source route), lsrr (loose source
route), rr (record packet route), and ts
(timestamp). The absence of a particular option
may be denoted with a '!'.
tcpoptions spec
Match if the TCP header contains the comma-separated
list of options specified in spec. The
supported TCP options are:
mss (maximum segment size), window (tcp window
advertisement), sack (selective ack), ts (rfc1323
timestamp), and cc (rfc1644 t/tcp connection
count). The absence of a particular option may
be denoted with a '!'.
established
TCP packets only. Match packets that have the RST
or ACK bits set.
setup TCP packets only. Match packets that have the SYN
bit set but no ACK bit.
tcpflags spec
TCP packets only. Match if the TCP header
contains the comma-separated list of flags
specified in spec. The supported TCP flags are:
fin, syn, rst, psh, ack, and urg. The absence of a
particular flag may be denoted with a '!'. A rule
that contains a tcpflags specification can never
match a fragmented packet that has a non-zero
offset. See the frag option for details on
matching fragmented packets.
icmptypes types
ICMP packets only. Match if the ICMP type is in
the list types. The list may be specified as any
combination of ranges or individual types
separated by commas. Both the numeric values and
the symbolic values listed below can be used. The
supported ICMP types are:
echo reply (0), destination unreachable (3),
source quench (4), redirect (5), echo request
(8), router advertisement (9), router
solicitation (10), time-to-live exceeded (11), IP
header bad (12), timestamp request (13),
timestamp reply (14), information request (15),
information reply (16), address mask request (17),
and address mask reply (18).
There is one kind of packet that the access device MUST always discard, that is an IP fragment with a fragment offset of one. This is a valid packet, but it only has one use, to try to circumvent firewalls.
An access device that is unable to interpret or apply a deny rule MUST terminate the session. An access device that is unable to interpret or apply a permit rule MAY apply a more restrictive rule. An access device MAY apply deny rules of its own before the supplied rules, for example to protect the access device owner's infrastructure.