RFC 3846 (rfc3846) - Page 2 of 8
Mobile IPv4 Extension for Carrying Network Access Identifiers
Alternative Format: Original Text Document
RFC 3846 MIPv4 Extension for AAA NAIs June 2004
9. Normative References . . . . . . . . . . . . . . . . . . . . . 6
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
1. Introduction
When building networks one would like to be able to have redundancy.
In order to achieve this, one might place multiple AAA servers in one
domain. When a mobile node registers via a visited network, the
authentication will be handled by one of the AAA servers in the home
domain. At a later point, when the mobile node moves to another
visited domain it again has to be authenticated. However, due to the
redundancy offered by the AAA protocol, it can not be guaranteed that
the authentication will be handled by the same AAAH server as the
previous one, which can result in the new AAAH not knowing to which
HA the session was assigned. This document defines a Mobile IP
extension which can be used to distribute the information needed to
resolve this.
Furthermore, the only information that is normally available about
the home agent in the registration request is the IP address as
defined in RFC 3344 [5]. Unfortunately this may not be enough since
some AAA infrastructures (such as Diameter [6]) use realm based
routing; such a AAA infrastructure needs to know the FQDN identity of
the home agent to be able to correctly handle the assignment of the
home agent. A reverse DNS lookup would only disclose the identity of
the Mobile IP interface for that HA IP address, which may or may not
have a one-to-one correspondence with the home agent FQDN identity.
This is a reason for the HA to also include its own identity in the
registration reply. The MIP v4 extension defined in this document
also has a subtype defined by which this may be done. The HA
identity can then be included by the mobile node in later
registration requests when changing the point of attachment.
2. Requirements terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [1].
The Mobile IP related terminology described in RFC 3344 [5] is used
in this document. In addition, the following terms are used:
AAAH
One of several possible AAA Servers in the Home Network
Jhansson & Johansson Standards Track