Mobility support in RADIUS and Diameter

Pivi Savola
Helsinki University of Technology
May 28, 2003
Abstract
This paper focuses on describing some of the possible implementations of authentication, authorization and accounting (AAA) using RADIUS and Diameter protocols
in the context of user mobility and roaming. The focus is on established TCP/IP-based
networks and the protocol support for mobility in RADIUS and Diameter.
The extensibility of both protocols allows for several different approaches, and
enables transferring a wide variety of information. This allows communicating different kinds of network access data, including configuring voluntary or mandatory
tunnels to the home network, Mobile IP and IPv6 network access.
Request forwarding by proxies and proxy chaining mechanisms in both protocols
are examined. The establishment of request forwarding relationships is not covered
by the RADIUS protocol, and some proposed solutions are presented. In addition to
more sophisticated request forwarding procedures, Diameter also has mechanisms for
discovering new Diameter servers.

1 Introduction
Just a decade ago most users had a static connection to Internet using a certain computer
and Internet Service Provider (ISP). The number of mobile users has grown in the last
decade. These users have a need to access resources in their home networks and the Internet
from multiple different locations possibly outside their home domain using the same piece
of connection equipment. This user mobility from one network to another without separate
service agreements with each temporary domains ISP is called roaming. [23]
This paper focuses on the possible implementations of authentication, authorization and
accounting (AAA) and user roaming and mobility in established TCP/IP-based networks.
The basic concepts of authentication, authorization and accounting are explained in in D.
Comers book "Internetworking with TCP/IP" [1].
The examined protocols are Remote Authentication Dial-In User Service (later RADIUS)
which was originally described by C. Rigney, S. Willens, A. Rubens and W. Simpson in
Request For Comments (RFC) 2058 [5]. The protocol has later been updated in other
RFCs [6, 17]. The other protocol described is Diameter, which was chosen as a successor
for RADIUS. The Diameter protocol specification is still a work in progress. The current
status of the Diameter project can be seen in the Internet pages of the Internet Engineering
Task Forces (IETF) AAA Working Group [28].
1

HUT TML 2003

T-110.551 Seminar on Internetworking

For the purposes of this paper it is assumed that the user has a means of connecting to the
local network and communicating with the local hosts. If the local network is not the users
home network, it is called foreign network.
The mediation of AAA information requires trust between the participating parties. Because of space constraints the problem of trust, certificate and key management between
the foreign and home domains has been left out of this paper, and the possible architectures
are touched only briefly when the description of the protocol functionality requires it.

2 Base protocol support for mobility

In this chapter the basic characteristics of the RADIUS and Diameter protocols are briefly
described. The basic protocol definitions of RADIUS, and especially Diameter provide
some mechanisms that can be utilized for mobility. The most notable of these is request
forwarding.

2.1 RADIUS protocol

The RADIUS [17] protocol as originally specified was intended to serve the purposes of
dial-in access to networks. In dial-in network access the user calls a Network Access
Server (NAS) with a modem thorough PSTN phone lines. As the number of users grew,
configuring each user to the correspondingly growing number of NASes made necessary a
centralized user authentication, authorization and accounting management.
In the basic RADIUS protocol model the user connects to the NAS, who forwards the
user identification data to a centralized RADIUS server. The server maintains a database
of users and the details of the services to be delivered to each user. The RADIUS server
will then send the NAS a reply telling it to either accept or reject the users connection
request, and configuration information about the kind of service to be delivered to the user.
Alternately, if extra security is desired, the RADIUS server may send a numeric challenge
thorough NAS to the user, and only grant network access upon a satisfactory answer to the
challenge. In addition to these authentication and authorization requests NAS may also
originate accounting requests, to which it will receive replies. Because of this client-server
protocol arrangement, NAS is often referred to as the client or RADIUS client. Fig. 1
illustrates this consept.
RADIUS protocol packets are carried inside UDP datagram payload. The RADIUS protocol uses UDP for several reasons of which the most important is the possibility to control
packet resending mechanism at the application level. [17] This permits server-specific
timeouts, and using backup or different servers whenever necessary. The communication
between RADIUS client and server is protected by a shared secret, which is used to authenticate the messages sent by each party. User passwords are encrypted with the RSA
Message Digest Algorithm MD5. [3]
A RADIUS message has a header containing information about the message type, length,
authentication information and an identifier, which allows requests ant their replies to be
related together. The rest of the message consists of attribute 3-tuples of attribute code
2

HUT TML 2003

T-110.551 Seminar on Internetworking

Figure 1: NAS acting as a client for RADIUS server

identifying the attribute name, a length field and attribute value. The attributes can be
categorized into four groups: RADIUS protocol mangement attributes, user identification
and authentication attributes, authorization attributes which detail the type of service to be
delivered to the user and accounting attributes which tell about service usage. Accounting
attributes are described in more detail in [18]. The type of RADIUS message and the
particular RADIUS implementation define, what attributes are sent. [17]
In addition to the basic set, several additional attributes and their usage have been defined in RADIUS protocol extensions. Examples of Radius extensions include attribute
sets for supporting Extensible Authentication Protocol (EAP) and Tunnel Protocol support
[21, 20]. This extensibility of the protocol by adding new attributes has proved to be a
powerful tool. All possible data or connection types does not have to be known in advance,
since given NAS support, even large amounts of configuration data can be communicated
over the network and new attribute triples can be added without disturbing the existing
implementations.
This extensibility allows an useful functionality for mobility: request forwarding. If necessary the RADIUS server may act as a proxy. The server, upon receiving an access-request
it cannot answer, may forward the request by acting as a client to another RADIUS server,
which is sometimes called the remote server. The response the server receives from the
remote server is then forwarded to the client. Essentially this allows RADIUS authentication requests to be directed to a certain RADIUS server from several network access
points within the same domain and within certain limitations, even between domains. The
RADIUS protocol itself is essentially stateless, so this requires the RADIUS server implementation to maintain internal transaction state. [17]
The problems with this approach include the need for shared secret between all the RADIUS servers in the forwarding network, and the difficulty of configuring the server a
request is to be forwarded to. End-to-end security is also impossible because of the need
for each of the servers to modify some of the protocol attributes over which the MD5
checksum is calculated.
Some RADIUS implementations propose to solve the RADIUS server discovery problem
by adding a separate database of AAA servers or information about the AAA servers in the
3

HUT TML 2003

T-110.551 Seminar on Internetworking

DNS system. [9, 23] This does not however, solve inter-domain security problems since a
shared secret and trust relationship between organizations is still required, especially since
RADIUS does not possess auditing features. Additionally, not all RADIUS implementations are compatible, and therefore a forwarding arrangement between organizations can
be difficult to arrange.

2.2 Diameter protocol

As the number of users, points of access, offered services and their complexity grew, it
became clear RADIUS could not meet all the AAA protocol requirements in an orderly
fashion. The Diameter protocol was chosen as the successor of RADIUS, and is still a work
in progress. Significant changes include specified failover mechanisms in cases of server
outage and transport reliability, better security features and explicit support for agents and
request forwarding. [29]
Instead of UDP Diameter runs on top of TCP or SCTP, and has features to support structured connection set-up and closing, including heartbeat and error messages. The connections can also be encrypted using IPsec architecture [1] or TLS [10] Both of these features
are particularly important for accounting messages.
Backward compatibility with RADIUS has been maintained to some extent, and Diameter
messages are similar in structure to RADIUS messages. Diameter protocol specifies a short
header with message type, length, and application, hop-by-hop and end-to-end identifiers.
The header is followed by a number of attribute-value pairs (AVP). The included AVPs
depend on the type of message. Some AVPs are used by the protocol itself and others
are used to carry different kinds of AAA data. Diameter protocol is extended similarly to
RADIUS by adding new AVPs. [29]
Unlike RADIUS, Diameter is a peer-to-peer protocol. There are 6 different kinds of roles
a Diameter node can take. Diameter clients perform network access control by sending
Diameter requests to Diameter servers, who perform authentication, authorization and accounting tasks for a domain. Proxy Agents forward request and response messages based
on their Diameter routing table and routing-specific AVPs in a Diameter message. They
may also do domain specific policy decisions and therefore sometimes have to modify
message AVPs. Proxy Agent may also originate Diameter messages if it has needed to
change a Diameter servers decision. Relay Agents forward requests and responses, but do
not make policy decisions and therefore do not change non-routing specific AVPs. Redirect Agents do not forward messages between clients and servers, but instead reply with
routing information about a suitable server in order to allow for a more direct communication. Lastly, Translation Agents perform protocol translation between Diameter nodes and
RADIUS (or other AAA protocol) servers which are located in the same network. [29]
In RADIUS protocol the support for forwarding requests to other RADIUS servers was
mostly implicit, which posed several problems for mobility support. Diameter solves many
of these problems with explicit protocol support for Proxy, Relay and Redirect Agents.
In Diameter there are several alternative mechanisms for determining the correct recipient
of an AAA request. Proxy and Relay Agents can be chained as in RADIUS, but the explicit
support for chaining results in more resilient architecture in case of errors. A Diameter
4

HUT TML 2003

T-110.551 Seminar on Internetworking

node can also query a Redirect Agent for the correct recipient of a an AAA request for a
user of certain domain.
The ability of Proxy Agents to modify request and response messages takes into consideration the consequences of incomplete trust between two different administrative domains,
and allows for determining the amount of possible risk.
In addition to static, manually configured Diameter routing table entries, Diameter protocol
also contains a dynamic peer discovery mechanism. Diameter servers are encouraged to
maintain at least two (primary and secondary) connections to Diameter servers in each
administrative domain. If a route to a suitable server cannot be found other techniques can
also be employed. The possible methods include a Service Location Protocol version 2
(SLPv2) query [8] and NAPTR [22] and predefined guessed name queries to the Domain
Name System (DNS) by using the users Network Access Identifiers (NAI) [13] domain
part as the lookup key.
The identities and authorization of thus discovered Diameter nodes should be checked,
before the Diameter node tries to establish a connection. Valid entries can be added to the
Diameter routing table using a suitable record time to live.
When two Diameter nodes establish a connection, a capability negotiation is performed in
order to determine the peers protocol version numbers, supported extensions and security
mechanisms. The information is cached for future use. [29]
From mobility point of view the dynamic peer discovery mechanism and capability negotiation can enable user roaming between domains without a separate agreement and NAS
configuration between each Service Provider pair. This eases roaming management, while
Proxy Agents can be employed in the structure to regulate the amount of trust between
domains.

3 Mobility extensions
The base protocol in both RADIUS and Diameter has some support for roaming, but there
are also attribute set extensions to both that have special features to aid mobility and roaming. We examine two important extensions: tunnelling and mobile IP.

3.1 Tunnelling extensions

The simplest arrangement of mobility using RADIUS is to dial in to the Service Provider
NAS over PSTN phone lines. Phones are quite widespread, and the approach has an added
advantage of making home domain configuration simpler. This solution is workable, if
the required data speeds and connection prices are fairly low. It will, however, curtail the
possibilities of accessing local resources, as all communication will go thorough the home
network.
As an alternative a tunnelling service may be used. The user connects to the Internet
in some foreign network, but uses tunnelling protocols to create a virtual private line to
the home network. Examples of tunnelling protocols are PPTP, L2F, L2TP and IPSEC.
5

HUT TML 2003

T-110.551 Seminar on Internetworking

Figure 2: Tunnelling setup procedure in RADIUS

If suitable security measures are observed, the result is a Virtual Private Network (VPN)
allowing a secure access to home network resources. [9]
In a tunnelling arrangement the user connects to a local NAS, which authenticates the
user with the users home RADIUS server either by querying it or by the RADIUS proxy
chaining mechanism. The necessary configuration information for tunnelling is usually
contained in the response packet. The extensions used for tunnelling are contained in RFC
2868, "RADIUS Attributes for Tunnel Protocol Support" [20]. Fig. 2 illustrates the tunnel
creation procedure.
RADIUS can be used to define tunnelling mandatory, an example extension using L2TP
is presented in by B. Adoba and G. Zorn in RFC 2194 [16]. In the case of a mandatory
tunnel, the system functionality resembles a dial-in access to the home network except that
the connection media is Internet instead of PSTN phone line. This way the local ISP does
not have to dedicate special resources to tunnelling users to a certain network. Instead
a connection is dynamically created to a tunnel server whenever needed. The attributes
needed for carrying tunnelling accounting data are defined in [19].
Diameter has no tunnelling extensions defined at this point of time. [28]

3.2 RADIUS and IPv4 (Mobile IP)

The Internet address basic routing scheme is hierarchical and fairly static, and therefore
does not easily lend itself to quick topology changes. Mobile IP [27] establishes a way for
a user to move from their home network to other foreign networks while still maintaining
their network identity. The basic method employed is IP in IP tunnelling. When the user
away from the home network, the Mobile IP the user, called also Mobile Node (MN) has
two network identities: the static home address, and a temporary care-of address related
6

HUT TML 2003

T-110.551 Seminar on Internetworking

Figure 3: Mobile IP communication without reverse tunnelling

to the foreign network the node currently inhabits. The node provides a host called Home
Agent (HA) in its home network information about its current local network. The HA then
receives the packets destined to the Mobile Nodes home address and tunnels them to the
foreign network to a host called Foreign Agent (FA) which delivers them to the Mobile
Node. FA can also act as a default router for the local networks registered mobile nodes.
The packet forwarding procedure can be seen in Fig. 3.
The packets sent by the mobile node can also be tunnelled back to the home network and
then sent to their destination by the HA. This arrangement is called reverse tunnelling. [25]
One scenario requiring reverse tunnelling is the use of Network Address Translation (NAT)
in users home network. Since only the router/firewall implementing NAT at the edge of
home network is aware of the address mapping, all communication between inside and
outside hosts must flow thorough the router/firewall.
Reverse tunnelling can also be mandated by the home domains security policies, if all
connections to hosts outside the home network must be supervised by the home networks
firewall. Examples of this kind of supervision include restrictions on the allowed protocols
and ports, and the requirement of initiating all connections from inside the home network.
A third circumstance needing reverse tunnelling is if the foreign network routes and possibly filters packets based on the source address. This is fairly commonly done to prevent
different kinds of spoofing and resource-stealing attacks, and in pheripheral networks many
routers and firewalls silently drop packets where the source address and source network do
not match. Reverse tunnelling allows topologically correct source IP addresses.
While the Mobile IP defines a way for the mobile node to authenticate itself to the FA (the
Mobile-Foreign Authentication extension), RADIUS also has an extension [24] specifically to allow for various authentication mechanisms and provide extra security in particu-

HUT TML 2003

T-110.551 Seminar on Internetworking

lar by making challenges possible.

Connecting to Internet thorough a foreign domain requires co-operation of both the home
and local service provider, as the user will be using the local providers network resources,
but will authenticate itself to the home provider. These problems are proposed to be solved
by an AAA infrastructure, which will enable inter-domain authentication, authorization
and accounting. The AAA requirements for Mobile IP have been defined by S. Glass, T.
Hiller, S. Jacobs and C. Perkins in RFC 2977, "Mobile IP Authentication, Authorization
and Accounting Requirements". [23]
In the most basic model, the mobile node connects to the provider of the required service,
called attendant. In the case of Mobile IP the Foreign Agent takes usually the role of
attendant. Because usage of resources is usually controlled, the attendant will act in the
traditional role of NAS in connecting to the local AAA server (AAAL). The AAAL in turn
will contact a server in the mobile nodes home domain (AAAH) for authentication of the
mobile nodes credentials, and for authorization information.
When accounting records are generated in the foreign network, they are similarly forwarded to the users home accounting authority. In case of commercial networks, the scale
of resources granted reflects the amount of trust between the two administrative domains.
The standardized method of identifying a user (especially in tunnelling or roaming contexts) is Network Access Identifier (NAI). [13] NAI is of the form user@domain, where
user identifies the mobile node, and domain the nodes home network or administrative
realm.
When the mobile node connects to the local network, NAI can be used to determine where
the local RADIUS server can send the authentication and authentication requests and later
accounting data.
In fact it is possible for a mobile node to connect to foreign network without a home
IP address, as it can be provided in the attributes of the authentication reply and other
configuration data from the home network AAAH. The extensions for this are described
by P. Calhoun and C. Perkins in RFC 2794. [15]
RADIUS does not provide for mechanisms of establishing trust between two different
domains. Agreements between service providers are certainly possible but are not scalable
in the long run without a proxy architecture. [14] In a proxy architecture the number of
needed shared keys and bilateral agreements is reduced by a hierarchical arrangement of
RADIUS proxies, whose purpose is to route AAA traffic from one network to another. In
addition policy management can be implemented in proxies by modifying the RADIUS
messages if needed. Broker architectures, where each trusts a third party broker server
have also been proposed. [23] Some implementations add entries for AAA hosts in the
DNS system. [9, 23] All these approaches present their own set of security problems,
which are outside the scope of this document.

3.3 RADIUS and IPv6

In IPv6 [11] the routing scheme is different from Mobile IP. Each host has a more or less
static home address. When the host roams thorough foreign networks it acquires a list
8

HUT TML 2003

T-110.551 Seminar on Internetworking

Figure 4: In IPv6 the traffic is directed to the care-of address

of care-of addresses thorough a stateless autoconfiguration or a stateful procedure such as

DHCPv6. [12] When the care-of address changes, the mobile host informs Home Agent in
the home network and its communication partners about the current address. Home Agent
tunnels the packets sent to the mobile hosts home address, which then performs a binding
update operation, so that the sender will send the next packets inside a timeout to the careof address. [2] One course of events leading to a binding update operation is shown in
Fig. 4. In the figure a user is roaming outside home network, while another host in a third
network wishes to initiate communication with the roaming user.
In full IPv6 networks The Foreign Agents are not employed, and therefore there may not
be an obvious candidate to take on the role of attendant. If dial-in access is not employed,
the role of NAS can be filled for example by the local router or DHCP server. [26]
In some cases the NAS may not always know whether a user will be using IPv4, IPv6 or
both with IPv6 transmitted inside IPv4, and therefore using both attribute sets at the same
time is permissible. If tunnelling is required, the related tunnel attributes should be used.
[20]

3.4 Diameter mobility extensions

Diameter can be used in authenticating, authorizing a Mobile Node and accounting for
services provided. The DIAMMIP application defines the necessary AVPs and their usage.
[30] Unlike in RADIUS, there is no need to separately define a way for building an AAA
infrastructure because of the intra-domain capabilities of Diameter protocol.
The basic model of communication is similar to RADIUS. When a Mobile Node (MN)
arrives at a foreign network, it will contact a Foreign Agent (FA) to be able to contact
the network. FA in turn will request authentication and authorization from the foreign
9

HUT TML 2003

T-110.551 Seminar on Internetworking

Figure 5: AAA relationship initiation in Diameter when using Mobile IP (IPv4)

AAA authority, AAAF. Foreign AAAF, a Diameter node, will then determine the Mobile
Nodes home Diameter server and forward the credentials to the home Diameter server,
also called home AAA authority (AAAH). If the AAAF is not capable of determining the
home Diameter server, it will forward the request to the closest probable hop towards it,
provided the security policy of the local domain allows it.
If the request does not ask for a particular Home Agent, the home Diameter server will
allocate one according to its internal policy, and send the information back with the request
response. Other configuration information like for example home address can also be sent
in the response. NAI [13] is used for user identification. Fig. 5 shows forwarding the
access request to the home Diameter server and the allocation of a home agent.
In some cases it is also possible to allocate the Home Agent in a foreign network. This is
negotiated between the home and foreign Diameter servers. [30]
When the number of networks grow, the amount of security associations (SA) between
domains becomes large, and shared secrets between Home and Foreign Agents are no
longer practical. The problem has been proposed to be solved with Key Distribution Centre (KDC) structure in the Diameter servers. The necessary session keys are created in
the Diameter server in the network that the Home Agent resides in after the authorization
phase. The keys for Home and Foreign Agents are propagated in Diameter protocol messages, while Mobile Node has its own procedure where the key is created from a nonce by
cryptography by the MN and home Diameter server using HMAC-MD5. [4]

10

HUT TML 2003

T-110.551 Seminar on Internetworking

4 Conclusion
In this paper we have examined the features that support for user mobility and roaming in
RADIUS and Diameter AAA protocols.
RADIUS support for mobility is based on the implicit possibility of forwarding requests.
Correspondingly, in RADIUS the different mobility architectures rely on building a network of other trusted RADIUS servers by proxy chains. The specifications of each implementation are covered in different extensions.
Diameter has more sophisticated support for mobility, including a way to discover new
Diameter nodes, and a more sophisticated forwarding system. Mobile IP is also supported.
In large scale networks Diameter is much preferable to RADIUS because of several new
features including peer discovery, end-to-end security and protocol error messages which
make the protocol more extensible, interoperable and reliable. The strengths of Diameter
lie especially in roaming user authentication and authorization and providing accounting
records. AAA using Diameter also requires a more limited amount of trust between the
participating operators. However, the Diameter protocol is considerably more complex
than RADIUS, and therefore may not gain popularity in systems where processing and
memory resources are scarce, for example in embedded systems.

References
[1] Comer E. Douglas, "Internetworking with TCP/IP, Principles, protocols and architecture", Prentice Hall 2000
[2] Gai S., "Internetworking
http://www.ip6.com/us/book/

IPv6

with

Cisco

Routers"

(network

edition),

[3] S. Dusse and R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992.
[4] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed- Hashing for Message Authentication. RFC 2104, February 1997.
[5] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In
User Service (RADIUS)", RFC 2058, January 1997
[6] Rigney, C., Rubens, A., Simpson, W. and Willens S., "Remote Authentication Dial In
User Service (RADIUS)", RFC 2138, April 1997.
[7] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[8] Veizades J., Guttman E., Perkins C. and Kaplan S., "Service Location Protocol", RFC
2165, June 1997
[9] Aboba B., Lu J., Alsop J., Ding J. and Wang W., "Review of Roaming Implementations", RFC 2194, September 1997
[10] Dierks T. and Allen C., "The TLS Protocol Version 1.0", RFC 2246, January 1999
11

HUT TML 2003

T-110.551 Seminar on Internetworking

[11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC
2460, December 1998.
[12] T. Narten and Thomson, S., "IPv6 Stateless Address Autoconfiguration", RFC 2462,
December 1998.
[13] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January
1999.
[14] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[15] Calhoun, P. and C. Perkins, "Mobile IP Network Address Identifier Extension, RFC
2794, March 2000.
[16] Aboba B. and Zorn G., "Implementation of L2TP Compulsory Tunneling via RADIUS", RFC 2809, April 2000
[17] Rigney, C., Rubens, A., Simpson, W. and Willens S., "Remote Authentication Dial
In User Service (RADIUS)", RFC 2865, June 2000.
[18] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000
[19] Zorn, G. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol
Support", RFC 2867, June 2000.
[20] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS
Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[21] Rigney, C., Willats W. and Calhoun P., "RADIUS Extensions", RFC 2869, June 2000
[22] Mealling M. and Daniel R., "The Naming Authority Pointer (NAPTR) DNS Resource
Record", RFC 2915, September 2000
[23] Glass S., Hiller T., Jacobs S. and Perkins C., "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000
[24] Calhoun, P. and C. Perkins, "Mobile IP Foreign Agent Challenge/Response Extension", RFC 3012, December 2000.
[25] Montenegro, G., "Reverse Tunneling for Mobile IP (revised)", RFC 3024, January
2001.
[26] Aboba B., Zorn G. and Mitton D., "RADIUS and IPv6", RFC 3162, August 2001
[27] Perkins C., "IP Mobility Support for IPv4", RFC 3344, August 2002
[28] IETF Authentication, Authorization and Accounting (aaa) working group home page,
http://www.ietf.org/html.charters/aaa-charter.html, 24.3.2003
[29] Calhoun P., Loughney J., Guttman E., Zorn G. and Arkko J., "Diameter Base
Protocol", http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-17.txt, December 2002, Work in progress
[30] Calhoun P., Perkins C. and Johansson T., "Diameter Mobile IPv4 Application", http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-13.txt, October 2002, Work in progress
12