Mobile IPv4 Extension for Carrying Network Access Identifiers
RFC 3846
|
| Document |
Type |
|
RFC - Proposed Standard
(June 2004; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 3846 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Thomas Narten
|
|
Send notices to |
|
(None)
|
Network Working Group F. Johansson
Request for Comments: 3846 ipUnplugged
Category: Standards Track T. Johansson
Bytemobile
June 2004
Mobile IPv4 Extension for Carrying Network Access Identifiers
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
When a mobile node moves between two foreign networks, it has to be
re-authenticated. If the home network has both multiple
Authentication Authorization and Accounting (AAA) servers and Home
Agents (HAs) in use, the Home AAA server may not have sufficient
information to process the re-authentication correctly (i.e., to
ensure that the same HA continues to be used). This document defines
a Mobile IP extension that carries identities for the Home AAA and HA
servers in the form of Network Access Identifiers (NAIs). The
extension allows a Home Agent to pass its identity (and that of the
Home AAA server) to the mobile node, which can then pass it on to the
local AAA server when changing its point of attachment. This
extension may also be used in other situations requiring
communication of a NAI between Mobile IP nodes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements terminology . . . . . . . . . . . . . . . . . . . 2
3. NAI Carrying Extension . . . . . . . . . . . . . . . . . . . . 3
3.1. Processing of the NAI Carrying Extension . . . . . . . . 3
4. HA Identity subtype . . . . . . . . . . . . . . . . . . . . . 4
5. AAAH Identity subtype . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
Jhansson & Johansson Standards Track [Page 1]
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
Show full document text