Internet DRAFT - draft-gondi-netlmm-pmip-aaam
draft-gondi-netlmm-pmip-aaam
NETLMM Working Group Vamsi Krishna.G,
Internet Draft Nazim Agoulmine,
Expires: August 2008 LRSM, UEVE,
Toan T,
Ecole Politechnique,
France
February 15, 2008
Mobility Management using AAA mobility extensions and Proxy Mobile
IPv4
draft-gondi-netlmm-pmip-aaam-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008). This version of this MIB
module is part of RFC 4748; see the RFC itself for full legal
notices.
Copyright (C) The IETF Trust (2008). The initial version of this
MIB module was published in RFC 4748; for full legal notices see the
Vamsi & Nazim Expires february 15, 2008 [Page 1]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
RFC itself. Supplementary information may be available at:
http://www.ietf.org/copyrights/ianamib.html.
Abstract
Mobility access through IPv4 and IPv6 provides seamless services for
the user terminals across different access networks. To provide
seamless continuity while the mobile is moving from one access
networks to another is provided by different mechanisms, on the whole
the proposed mechanisms provides mobility with special requirements
access mechanism. The foremost popular of the mobility mechanisms is
provided by Charles Perkins in mobile IPv4 IETF RFC 2002. There are
some of the issues that MIP doesn't provide as a total mobility
solution. The Proxy MIP is a mobility mechanism to ensure mobility
management of the user terminal in different access networks. This
method provides the network based mobility management without any
client interactions. By this method the signaling overhead and the
latency during the handover and roaming is reduced. In this proposed
mechanism the mobile node doesn't need to have support for the
mobility instead the access network provide the mobility for the user
terminal.
Even though the proxy mobile IPv4 provides the mobility management
there are some of the issues that have to be solved for the network
controlled mobility management. In this proposed draft we proposed
new mechanism using proxy mobile IP with the mobility extensions
provided by the AAA server at the time of authentication and
authorizing a user terminal. Later in the draft we discuss the novel
architecture and packet format for PMIP interactions with AAA of the
access networks.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................6
3. Proposed nouvelle solution for PMIP with integrated AAA
architecture of the 3GPP and Wireless networks....................8
4. AAA mobility extensions for PMIP integrated architecture......10
5. Overview of PMIP operation with new mobility extensions with MPA
and HA...........................................................11
6. Packet format for AAA mobility extensions, MPA and HA.........12
7. Sequence diagram of data and control information during the
mobile terminal roaming in access networks.......................23
8. Being at home network.........................................23
9. Security Considerations.......................................24
10. IANA Considerations..........................................24
Vamsi & Nazim Expires August 15, 2008 [Page 2]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
11. Conclusions..................................................25
12. References...................................................25
Full Copyright Statement.........................................27
Intellectual Property............................................27
1. Introduction
IP version 4 assumes that a node's IP address uniquely identifies
the node's point of attachment to the Internet. Therefore, a node
must be located on the network indicated by its IP address in order
to receive datagram's destined to it, otherwise datagram's destined
to the node would be undeliverable. For a node to change its point
of attachment without losing its ability to communicate, currently
one of the two following mechanisms must typically be employed:
a) The node must change its IP address whenever it changes its
point of attachment, or
b) Host-specific routes must be propagated throughout much of the
Internet routing fabric.
Both of these alternatives are often unacceptable. The first makes
it impossible for a node to maintain transport and higher-layer
connections when the node changes location. The second has obvious
and severe scaling problems, especially relevant considering the
explosive growth in of portable devices connected to internet.
The mobility management in the access networks is provided by the
mobile IP for the seamless continuity of the services during
handover and roaming. The traditionally user terminal does require a
mobile node enabled with a client mobile IP, in some cases the
devices can't be enabled with mobile IP, in this case the mobility
must be provided without changing the software configuration of the
devices and provide mobility from the access network side. By this
method the controlling of the mobility of the mobile terminal can be
more efficient.
The Proxy Mobile IP [2] solution based on Mobile IP approach, handle
the mobility management inside the network. Therefore network
entities will require more capability than in the standard Mobile IP.
The Foreign Agent is no longer capable to handle the mobility
management in this new scenario, so we need to enhance its
capabilities with the Mobility Proxing mechanism. This new entity
called Proxy Mobile Agent replaces the Foreign Agent in the visiting
network. It also handles the mobility registration with the Home
Vamsi & Nazim Expires August 15, 2008 [Page 3]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
Agent. This change is the most significant since the Mobile Node now
lies outside the mobility registration procedure. In fact, the Mobile
Node is not aware of its movement, the access networks deceives the
host to believe that it is stationary in its Home Network. Since the
Mobile Node does not need either movement detection or agent
registration, the advertisements are no longer necessary.
There are some of the requirements and features to be satisfied for
the PMIP for mobility management:
. Support Unmodified Hosts: As noted above, the protocol supports
mobility to the nodes that doesn't have capability of mobility.
. Airlink consumption: Mobility-related signaling over the air-
link is eliminated. Considering that Network Address Translation
(NAT) is ubiquitous in IPv4 networks, a mobile node needs to
send keep alive at short intervals to properly maintain the NAT
states. This can be performed by the MPA in the network which
does not consume any air-link bandwidth. The Agent Advertisement
is also eliminated in the protocol.
. Support the Heterogeneous Wireless Link Network: One aspect is
how to adopt the scheme to an access technology. Since Proxy
Mobile IPv4 is based on a heterogeneous mobility protocol, it
can be used for any type of access network.
. The other aspect is how to support mobility across different
access technologies. As long as the MPA can use the same NAI to
identify the MN for various access networks, roaming between
them is possible.
. Support the IPv4 and IPv6: As IPv6 increases in popularity, the
host will likely be dual stack.
Draft-leung-mip4-proxy-mode-03.txt proposes a proxy mobile IP
mechanism as shown in figure 1.
+----+ +-------+ +-------+ +-----+
| | | | | | | |
| MN | | MPA | | AAA | | HA |
| | | | | | | |
+----+ +-------+ +-------+ +-----+
Vamsi & Nazim Expires August 15, 2008 [Page 4]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
| | | |
| 1a | 1b | |
|<------------->|<----------->| |
| | | |
| 2 | | |
|-------------->| | |
| | 3 | |
| |----------------------->|
| | | |
| | 4 | |
| |<-----------------------|
| 5 | | |
|<--------------| | |
| | | |
| 6 | | |
|<------------->|<===========>|<========>|
| | | |
Figure 1. PMIP mechanism
Steps 1a and 1b involves layer 2 establishment with base station or
with an access point and performs authentication and authorization.
After successful authentication, MN does the DHCP request for the
authentication during step 2
As mentioned in the draft information of the mobile node and its
home agent information is passed to the MPA, in the step 3 with the
available information of the MN, MPA does sends the registration
request to the HA of the home network.
Step 4 does involves the HA authenticating the mobility registration
request from the MPA, sends the registration reply to MPA.
After receiving the registration reply MPA sends the home address to
the DHCP server. The DHCP server sends the DHCP reply to the MN.
During step 6 IPCP/NCP procedures get completed and the MN's IP
stack is ready to receive or send IP packets in case of 3GPP
network. In case of wireless network DHCP is used, the regular
DHCPREQUEST and DHCPACK messages are exchanged and the MN's IP stack
is configured with the assigned IPv4 address.
Even though the PMIP does provide the mobility solutions there are
issues of user identity, mobility context of the user from the home
network to the visiting network, assigning the home address to the
user from the visiting network. In this draft we propose a new
mechanism with the proxy mobile IPv4 as a mobility solution in
Vamsi & Nazim Expires August 15, 2008 [Page 5]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
networks. In this mechanism during mobile node access
authentication, MPA exchanges registration messages with HA to set
up a proper routing and tunnelling the packets from/to MN. In this
method during the authentication request of the mobile node is
passed through the NAS or AP of the visiting network, this is passed
to AAA server, authentication server checks the realm and does start
the authentication procedure at the time of initialling the
authorizing module of the mobile terminal it also initiates mobility
extension module where AAA server initiates MPA of the access
network and also informs the AAA server of the home network with the
mobility extensions for the request of the mobility parameters of
the user. The home AAA server interacts with the HA and collects the
details of mobile node parameters and sends back the details as a
reply for the request to the visiting AAA server. After the mobility
context transfer the MPA does mobility registration to the HA for
that mobile node. Later in this draft we provide more details of the
interactions between different components of the architecture,
packet formats and sequence of message exchanges during a mobility
session of a user mobile node during a handover.
2. Conventions used in this document
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Mobile Node (MN):
Any IPv4 node that has the ability to physically access or
roam across different networks. In Proxy Mobile IP, the Mobile
Node does not need the Mobile IPv4 protocol stack. MN is
provided with a long-term IP address on its Home Network - the
Home Address.
Corresponding Node (CN):
The peer node that sends/receives packets to/from MN.
Home Network:
Network that MN is registered which provides its Home Address
(long-term IP address that is issued to the Mobile Node).
Visited Network:
Current network where MN situates.
Old Visited Network:
The last network other than Home Network that the MN has left
for the current location (Visited Network).
Vamsi & Nazim Expires August 15, 2008 [Page 6]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
Home Agent (HA):
Data/routing anchor that maintains the location of the Mobile
Node and tunnels the datagrams from/to the Mobile Node while
it is away from home. HA takes part in the Mobility
Registration.
Foreign Agent (FA):
A router in the Visited Network that handles the registration
of the Mobile Node in the Visited Network, may offer the
Foreign Agent Care-of Address to tunnel the packet to the
Mobile Node. The Foreign Agent may serve as the default router
for the Mobile Node.
Mobility Proxy Agent (MPA):
Mobile IPv4 entity that offers proxy mobility service for a
Mobile Node by performing the registration function on the
host's behalf. It helps tunneling data.
Agent Advertisement:
An advertisement message constructed with the special
extension to declare the service offered by an agent (Home
Agent or Foreign Agent).
Access Point (AP):
Point of attachment that connects the MN to network.
Home AAA Server (AAAH) and Foreign AAA Server (AAAF):
AAA server in the MN's Home Network and the AAA server in the
local network (Visited Network), respectively. The address of
the HA and MPA can be downloaded from the AAA Server (AAAH
and/or AAAF).
Care-of Address (CoA):
The termination point of a tunnel toward a Mobile Node,
playing role of intermediate destination for datagrams
forwarded to the Mobile Node while it is away from home. In
the Mobile IP, there are 2 types of care-of address: "Foreign
Agent Care-of Address" (address of the Foreign Agent that
registers the MN) and "Co-located Care-of Address" (address
that the Visited Network issues to the Mobile Node,
considered as a network interface of the Mobile Node in the
local network). In the Proxy Mobile IP, the Care-of Address
is the MPA's IP address.
Vamsi & Nazim Expires August 15, 2008 [Page 7]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
3. Proposed nouvelle solution for PMIP with integrated AAA architecture
of the 3GPP and Wireless networks
In this new mechanism, mobility registration of the user terminal is
performed by visiting access network and home access network. The
user terminal does general authentication mechanism with the
visiting access network with the help of EAP mechanism. The visiting
access network does receive the authentication request from the user
terminal from the NAS of the network. AAA of the visiting network
and home networks are modified so that they can communicate with the
HA and MPA of their respective networks. The visiting network
initiates the authentication and mobility extension method whenever
it receives the request from the NAS or AP of the access network.
During initiation of mobility extensions AAA mobility extension
process collects the data from the NAS request from the AAA server.
If ever the authentication initiation is done the mobility extension
does initiates the procedure for proxy mobile IP. AAA mobility
process sends a mobility extension request to the home network of
the terminal with the special attributes of the proxy mobile IP. The
Home AAA server does receive the request for the mobility extension
as well as the authentication. Home AAA server distinguishes the
proxy mobile IP packet with the code and the attributes of the
received packet. If ever the packet has to be proxy from a
intermediate AAA server, that server adds the proxy attribute to the
received packet and sends to the destination AAA server.
After receiving the mobility extension packet from the visiting AAA
server the home AAA server investigates the information available in
the packet. After processing the request the mobility extension
method prepares a request packet to the HA of the access network.
This packet contains details of user id and its parameters. The HA
server receives the request and with the user ID of the request it
extract the information of SID, keys, home address and home agent
address from the database. HA sends back the reply to the AAA of the
home networks with the above mentioned data. AAA server receives the
reply and process the information and sends back the reply message
to the visiting AAA server.
Visiting AAA server receives the reply from home server and process
the reply and stores the data of the user in a temporary database.
After processing the reply message, AAA server sends the MPA with a
request for the mobility. This request contains details of user ID,
SPI, keys, home address and home agent address. MPA receives the
packet starts the mobility registration of the user with details
from the AAA server.
Vamsi & Nazim Expires August 15, 2008 [Page 8]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
MPA server initiates the registration request of the user with the
home agent with the details provided by the AAA server. Registration
involves the user SPI and the shared key mechanisms with the key
available from the AAA server to the MPI. After successful
registration of the user with the HA, MPI modify the DHCP server
configuration with the user terminal details. These modifications
contain the details of MAC address and the home address of the user
in the DHCP server. After successful authentication of the user the
user terminal starts the DHCP request. The AP or the NAS of the
visiting network forward the request to the DHCP server. With the
MAC address of the user terminal the modified DHCP server sends the
reply to the user terminal with its home address. User terminal
receives the reply and configure the IP address to the home address.
Necessary modification has to be done on the visiting network to
accommodate the terminal with the ARP, etc.
+--------------+
|NAs sending |
|request for |
|authentication|
+--------------+
|
|
+---|-------------------------------------+ +-----------+
| | Visiting | | home |
| | AAA | | AAA |
| | +--------+ | | +-------+ |
| | |Authen | | | |Authent| |
| | /|tication|<--A-->| |ication| |
|+-------+ +--------+ / +--------+ | | +-------+ |
||check |----->|MN of |/ | | | |
||realm | |visiting|\ | | | |
|+-------+ +--------+ \ +----------+ | | +-------+ |
| | \| PMIP |<--B-->| PMIP | |
| | | Managemen| | | |Manage | |
|+--------+ +----------+ | | +-------+ |
||MN of | | | | | |
||Local | | | +--|--------+
||network | | | |
|+--------+ | | |
| | | | |
|+---------------+ | | |
|| Local | C | D
Vamsi & Nazim Expires August 15, 2008 [Page 9]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
||Authentication |--------+ | | |
|+---------------+ | | | |
| | | | |
| | | | |
+-------------------------|-------|-------+ |
| | |
+------+ +--------+ +-------+ +-----+
| User | | HA / | | | | User|
| DB |<->| MPA |<---E---->| HA |<->| DB |
+------+ +--------+ +-------+ +-----+
A - Mobile Node Authentication request and reply
B - AAA mobility Context management
C - AAA to MPA context transfer
D - AAA to HA context transfer
E - Mobile node registration request and reply
4. AAA mobility extensions for PMIP integrated architecture
In this section we describe the detailed architecture of AAA for
mobility extensions to provide mobility management during the
roaming of a user in different access networks. In this process
existing AAA architecture is modified to accommodate proxy mobile
IP. In general the authentication information of the users are
passed through the authenticator, this information is passed through
NAS or AP of the access networks. AAA server authenticates the
access networks AP or NAS initially and then process the user
authentication request depending on the realm of the user. In this
new method the mobility management of the user can be initiated
during the authentication process. In this process, due to parallel
operation of authentication and mobility management the overall
latency of the user during handover and initial access can be
reduced.
When the authentication module is initiated in the AAA server at the
request for authentication by the NAS or AP of the network, mobility
management process does initiates. The details of NAS or AP, user
details are processed and sent to the PMIP modules of AAA. AAA is
modified and new attributes and codes are added for supporting the
PMIP modules. As mentioned previously in the proposed solution
section with new extensions, AAA of the home network can communicate
with the visiting network can provide the mobility context
management. With these mobility extensions AAA server can
communicate with the MPA and HA of the access network.
Vamsi & Nazim Expires August 15, 2008 [Page 10]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
On first hand the visiting AAA server communicates with the home
network AAA server after receiving the authentication request using
the mobility extensions with the user information available from the
authentication request from the client using AAA mobile extension as
a request. When the home network receives the request packet the AAA
server process the information of the user. It sends a request to HA
with the new mobility extension requesting the details of the user.
HA after receiving the packet process the user details from its
internal database and sends back the reply packet with home address
and home agent address to the AAA home. Home AAA server sends back
the reply to the visiting AAA server with the user details as a
reply. After receiving the reply from the home AAA server the
visiting AAA process the information of the user and sends a request
for the mobility context with the new attribute request to the MPA.
The MPA receive the user data sent by the visiting AAA server and
temporarily stores in a local database. MPA with the available user
information starts authenticating with the HA. According to the
response the MPA sends the reply to AAA as a success or the failure
of the mobility registration of the user to visiting AAA server. To
clarification sake we kept all the attributes, data and code type
details to one section 6 of this document.
5. Overview of PMIP operation with new mobility extensions with MPA and
HA
MPA exchanges registration messages with HA to set up a proper
routing and tunneling the packets from/to MN. The MN broadcasts
messages containing MN's Network Access Identifier (NAI) to request
authentication/authorization. The AP transfers the request to the
local AAA server (AAAF). If the MN is away from home, it is clear
that the MN is out of the local authentication database; however,
the local AAA server can use the NAI to identify the MN's Home
Network. The authentication/authorization registration message then
will be transferred to the AAA Server (AAAH) in the Home Network.
Alongside with the authenticating validation, the AAAH searches
for the information of the MN stored in the HA, containing MN's HA,
NAI, and SPI. If the MN is back to its Home Network: the local AAA
server sends a message to HA to deregister the MN instead of
searching for the data.
The MN's information will be transferred to the AAAF, which will
deliver it to the MPA with the AP's MAC address included. Triggered
by the AAA server, the MPA exchanges messages with the HA to demand
for the Mobility Registration and Tunneling. The formats of the
Mobile IPv4 Registration Request (MIPv4 RRQ - sent by the MPA) and
Vamsi & Nazim Expires August 15, 2008 [Page 11]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
the Mobile IPv4 Registration Reply (MIPv4 RRP - sent back by the HA)
are specified as in the section.
After registration successful, MPA sends a message to inform DHCP
about the MN's arrival. It forces the DHCP server to update the
configuration file with the Mobile Node information. Finally, the
MPA informs the AAAF about the registration successful. The
Authentication Accept message is sent to the NAS granting network
access to the MN. After the authentication success, the MN sends a
Binding DHCPDISCOVER to request for the IP address. This message is
formatted as described by the DHCP protocol (the CIADDR field is
filled with the MN's IP). By searching the information of the Mobile
Node in the configuration, the DHCP server replies with a DHCPOFFER
message in which the YIADDR field is filled with the MN's Home
Address and the default gateway address is MPA's. Next, the MN and
DHCP server exchange the DHCPREQUEST and DHCPREPLY to complete this
procedure. The MN is then ready to connect to the network with its
Home Address.
6. Packet format for AAA mobility extensions, MPA and HA
The AAA server builds Mobility Request message from the Access
Request or EAP Request from the NAS. Remark that the intermediate
AAA servers just pass through this step, adding Proxy Attribute and
forwarding the Request.
Mobility Request format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code (1 byte)| Identifier(1B)| Length (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Vamsi & Nazim Expires August 15, 2008 [Page 12]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
Note: the codes and the attributes in this document are taken as
reference these can be changed according to the IANA consideration,
in this case we used available values for developing the prototype,
if there are any issues regarding these values we can change them in
the next version.
Code = (1 byte) Mobility_Request = 60.
Identifier: (1 byte) number to match the Request/Reply.
Length: (2 bytes) length of the message, including Code, Identifier,
Length, Authenticator, Attributes. In the case that there is only
mobility attribute, length = 350
Authenticator: The Authenticator field is 16 bytes. The most
significant octet is transmitted first. This value is used to
authenticate the reply from the RADIUS server, and is used in the
password hiding algorithm.
Attributes: Mobility Attribute:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1 byte) | Length (2 bytes) | User's ID (1B)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User's ID (256 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI (1byte) | Key (64 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = (1 byte) Mobility_Request_Attribute = 193.
Length (2 bytes) = Length of the message = 332.
User's ID: (256 bytes) extracted from the name of the user (ex:
userID@realm).
HA address: (4 bytes) Home Agent's IP address, filled with Zeros.
Vamsi & Nazim Expires August 15, 2008 [Page 13]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
Home Address: (4 bytes) Mobile Node's Home Address, filled with
Zeros.
SPI: 1 byte, filled with Zeros.
Key: (64 bytes) public key of the HA, filled with Zeros.
The AAAH will reply with a Mobility Response.
HA/MPA consultation
If AAA home server receives Mobility Request from a visiting server,
the AAAH sends message to HA to fill the information required in the
Mobility Request Attribute (fields that are filled with Zeros).
Remark that the AAAH sends the HA Consultation message only by being
triggered by the Mobility Request; the Access Request forces the
AAAH to deregister the MN (See Section 10).
- H1: Create a message from AAAH to the HA demanding for the
necessary information:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code (1byte) |Identifier (1B)| Length (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User's ID (256 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Point's MAC address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP's MAC address (cont) | MN's MAC address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN's MAC address (continue) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI (1 byte) | Key (64 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (continue) |
| |
Vamsi & Nazim Expires August 15, 2008 [Page 14]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code (1 byte) = HA_Consultation_Request = 63.
Identifier: (1 byte) number to match Request/Response.
Length (2 bytes) = total length of the message = 343
AP and MN's MAC address: These fields are practically used in the
message from AAA to MPA. In the message from AAA to HA, these fields
are filled with Zeros, and the HA just ignores it. But these fields
SHOULD appear in the HA Consultation Message to identify the format
of messages AAA-HA and AAA-MPA. It is very useful since the HA and
MPA in the same network are usually installed in the same server.
This identification simplifies the treatment of message in the
HA/MPA server.
Other fields are copied from the Mobility Attribute of the
authentication request.
- H2: HA looks for the required information in its database, save
the AP and MAC address fields. If the information can't be found
(this may be due to the modification of the administrator), HA will
pass this phase, so that the message will be left Zeros. That allows
the AAAH to detect the failure.
- H3: HA sends back the reply to the AAA after filling the request's
required fields and setting Code = HA_Consultation_Response = 64.
- H4: The AAAH replies the AAAF with a Mobility Authentication
Response, which is either an Accept or Reject message. The format of
these messages is as same as the request, with different code and
attributes:
If the message from HA is not filled with Zeros (successful
verification), the AAAH reply to the AAAF with Mobility Accept
message which is copied from the Mobility Request whose the
Attributes filled by the data gotten from HA. The Code field for
this message is: Code = Mobility_Accept = 61.
If the data from HA is filled with Zeros, the AAAH MUST reply the
AAAF with a Mobility Authentication Reject message, with Code =
Mobility Reject = 62. The Mobility Reject message doesn't contain
the Mobility_Attribute, and may include Reply-Massage Attribute
which contains the error message shown to the user [10]:
Vamsi & Nazim Expires August 15, 2008 [Page 15]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type = 18 | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type: 18 for Reply-Message.
Length: length of the attribute, including Type and Length field.
Text: The Text field is one or more octets, and its contents are
implementation dependent. It is intended to be human readable, and
MUST NOT affect operation of the protocol. If the registration
failed, this field is filled with the message extracted from the MPA
Mobility Registration Reply.
Mobility Registration
After receiving the Mobility Accept message, the AAAF makes MPA
handle the Mobility Registration procedure. The MPA exchanges
messages with the HA and DHCP server, then informs the AAAF about
the result (success or not). The Mobility Authentication Reject
causes the AAAF to send the Reject message to the NAS and terminate
the whole procedure.
- MR1: AAAF sends a MPA Mobility Registration Request message to
MPA: the format is as same as HA Consultation message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1 byte)| Identifier(1B)| Length (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User's ID (256 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Point's MAC address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP's MAC address (cont) | MN's MAC address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN's MAC address (continue) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address (4 bytes) |
Vamsi & Nazim Expires August 15, 2008 [Page 16]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI (1 byte) | Key (64 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (continue) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (1 byte) = MPA_Mobility_Registration_Request = 65.
Identifier: (1 byte) number to match Request/Response.
Length (2 bytes) = total length of the message = 343.
Other fields save AP and MN's MAC address are copied from the
Mobility Attributes of the Authentication Response.
- MR6: MPA Mobility Registration Reply to AAAF:
The MPA sends back the reply to the AAA after successful
communication with the DHCP server, or if it detects any error
(registration unsuccessful, DHCP server refusal to register the
Mobile Node, or requests cannot reach the destination). In this
latter the MPA sends a reject message to the AAA server (reply with
response = 1 or 2).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1 byte) | Identifier(1B)| Length (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response (1B) | Message
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = MPA_Mobility_Registration_Reply = 66
Response = 0 if successful, = 1 if unsuccessful with message, = 2 if
unsuccessful without message.
In the unsuccessful case (Response != 0), AAA will sends an
Access_Reject message to the NAS. Otherwise, if the Response Code =
Vamsi & Nazim Expires August 15, 2008 [Page 17]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
1, the text in the Message field can be used in the Reply-Message
Attribute in the Mobility Authentication Reject message [8].
- MR2: Registration
For the convenience of use of Client Mobile (Mobile IPv4) and Proxy
Mobile, the MPA and HA should use the Mobility Registration Request
as specified as in RFC3344 (this simplicity allows the MPA to handle
the Mobile IP protocol):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |S|B|D|M|G|r|T|x| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 1 (Registration Request)
S Simultaneous bindings. If the 'S' bit is set, Home
Agent retains the Mobile Node's prior mobility bindings.
B Broadcast datagrams. If the 'B' bit is set, HA tunnel to
MN any broadcast datagrams that it receives on the home network.
D Decapsulation by mobile node. If the 'D' bit is set, the
Mobile Node will decapsulate datagrams which are sent to the care-of
address. That is, the mobile node is using a co-located care-of
address. This bit is only for the Mobile Node that support mobility:
D=0 for Proxy Mobile IP.
Vamsi & Nazim Expires August 15, 2008 [Page 18]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
M Minimal encapsulation. If the 'M' bit is set, the mobile
node requests that its home agent use minimal encapsulation for
datagrams tunnelled to the mobile node.
G GRE encapsulation. If the 'G' bit is set, HA is
required to use GRE encapsulation for datagrams tunnelled to the
mobile node.
r Sent as zero; ignored on reception. SHOULD NOT be
allocated for any other uses.
T Reverse Tunnelling requested. T = 1 with Proxy Mobile
IP.
x Set as zero; ignored on reception.
Lifetime
The number of seconds remaining before the registrations considered
expired. A value of zero indicates a request for deregistration. A
value of 0xffff indicates infinity.
Home Address
The IP address of the mobile node.
Home Agent
The IP address of the mobile node's home agent.
Care-of Address
The IP address for the end of the tunnel. Here is the MPA's.
Identification
A 64-bit number, used for matching Registration Requests with
Registration Replies, and for protecting against replay attacks of
registration messages.
Extensions
The fixed portion of the Registration Request is followed by some
extension. In this document we don't discuss about the mobility
registration extension.
Vamsi & Nazim Expires August 15, 2008 [Page 19]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
HA reply with Mobility Registration Reply, formatted as specified in
RFC3344:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Code (1 byte)| Lifetime (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification (8 bytes) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 3 (Registration Reply)
Code A value indicating the result of the Registration
Request. (List of currently defined Code values [3]).
Registration successful:
0 registration accepted
1 registration accepted, but simultaneous mobility bindings
unsupported
Registration failed: Code > 1
Lifetime 2 bytes.
Home Address
The IP address of the mobile node.
Home Agent
The IP address of the mobile node's home agent.
Vamsi & Nazim Expires August 15, 2008 [Page 20]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
Identification
Match the request/Reply (8 bytes)
Extensions:
In this document we don't discuss about the mobility registration
extension.
MR4: MPA sends DHCP Mobility Registration Request to DHCP server:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1 byte) | Identifier (1 byte) | Length (1B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address (continue) | Home Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address (continue) | Action (1B) | MPA's MAC add |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPA's MAC address (continue) (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPA's MAC add |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = DHCP_Mobility_Registration = 67
Identifier: match Request/Response
Length = 21: length of the message, including the Type and
Identifier fields
MAC address: MN's MAC address
Home Address = MN's Home Address.
Action: (1 byte) = 0 - binding update: the DHCP server updates its
configuration file with the MN's new entry:
Vamsi & Nazim Expires August 15, 2008 [Page 21]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
MN's MAC address --- MN's IP address --- Default Gateway = MPA's
MAC address
If Action = 1 - remove entry: cause the DHCP server to remove the
MN's entry in its configuration file. This action is used in the
Registration Revocation Procedure.
As receiving the message from the MPA, the DHCP server updates its
configuration with the information supplied by the MPA. Since then,
as soon as the DHCP server receives the (Binding) DHCPDSICOVER
message from the MN, it will exchange the messages with the MN
granting the MN keep its Home Address; also indicates the MPA as
MN's default gateway.
MR5: DHCP Mobility Registration Reply to MPA
The message is formatted as same as the reply from MPA to AAA
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1 byte) | Identifier(1B)| Length (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response (1B) | Message
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = DHCP_Mobility_Registration_Reply = 68
Length = length of the message including the Type and Identifier
fields
Response Code = 0: accept, = 1 reject with message, = 2 reject
without message.
If the response Code is other than 0, the MPA MUST response with the
AAA with MPA Mobility Registration Reply whose Response and Message
fields copied from DHCP Mobility Registration Reply message.
Message: this message will be used in the response from MPA to AAA.
Vamsi & Nazim Expires August 15, 2008 [Page 22]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
7. Sequence diagram of data and control information during the mobile
terminal roaming in access networks
+----+ +-------+ +-------+ +-------+ +-----+
| | | | | | | | | |
| MN | | AAA V | | MPA | | AAA H | | HA |
| | | | | DHCP | | | | |
+----+ +-------+ +-------+ +-------+ +-----+
| | | | |
| 1 | | | |
|<------------->| | | |
| | 2 | | |
| |<-----------------------| |
| | | | 3 |
| | | |<----------|
| | | | |
| | 4| | |
| |<-----------------------| |
| | | | |
| | 5 | | |
| |<------------| | |
| | | | |
| | | |6 |
| | |<---------------------|
| | | | |
| | | | |
In the step 1 the mobile node send the authentication request to
the NAS or the AP of the visiting network. The NAS forwards the
request to the AAAF server. The AAAF server identifies the request
and prepares the mobility and authentication mechanisms. In step 2
the AAAF sends a request to the AAAH for the for the mobility request
for the user with the ID from the authentication request from the
NAS. After receiving the request from the AAAF the AAAH sends the HA
for the user consultation request and HA responds with the details as
a response. The AAAH sends back the response to AAAF in step 4 as a
response with the user details, home address, home agent details and
the user temporary key to the AAAF. In step 5 the AAAF sends the user
details to the MPA. In step 6 MPA and HA does the registration for
the mobile node and provides the tunnel for mobility management.
8. Being at home network
As the MN returns its Home Network, this fact is revealed to the AAA
server (AAAH) by receiving a Access_Request from a NAS which it
finds an entry matching the Access_Request, the AAA server will
sends a HA Registration Revocation Request to HA which erases the MN
Vamsi & Nazim Expires August 15, 2008 [Page 23]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
entry in its Mobility Registration Database and sends an
MIPv4_Regstration_Revocation to the MPA on the last network that MN
has visited. Recall that the Mobility Request message makes the AAAH
send a HA Conslultation message in order to get information of the
MN, while the Access_Request makes the AAAH send a HA Registration
Revocation to erase the MN's mobility registration entry.
The message format is as same as the MIPv4 Registration Revocation
Request.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1B) | Identifier (1B) | Length (1B) | Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = HA_Registration_Revocation_Request = 4
Identifier: 1 byte
Length = 7
Home Address = MN's Home Address The HA replies with an ACK.
9. Security Considerations
The HA and the MPA to the RADIUS server transactions must be
adequately secured. Otherwise there is a possibility that fraudulent
values are received from a rogue RADIUS server. The new attributes
defined in this document do not introduce additional security
considerations.
10. IANA Considerations
The type of attribute PMIP MPA/HA with AAA, AAA new attributes and
codes configuration mode MUST be assigned by IANA. The value of the
attribute Framed-Protocol MUST also be assigned by IANA. In this
draft for demonstrating the prototype we have used available IANA
values assigned to the AAA.
Vamsi & Nazim Expires August 15, 2008 [Page 24]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
11. Conclusions
The Proxy Mobile IP is a development of the Mobile IP in which
the registration is done by the network entity. Hence, the Mobile
Node does not require the Mobile IP stack to roam over the network
without losing the IP address, so can be applied to the unchanged
devices. Using this proposed mechanism the authentication and the
mobility management of the user during the access is performed in
parallel, in this way the latency during the authentication and re-
authentication is reduced. In this mechanism using the context
management the control of user can be maintained according to the
access networks.
We already demonstrated the capabilities the propose solution
using a testbed. We developed the attributes and modules proposed in
this architecture and implemented over a live testbed. In the future
we want to enhance proposed architecture to address the issues which
may have to be addressed for certain functionalities proposed by the
working group.
12. References
12.1. Normative References
[1] Perkins C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
[2] Leung K., Dommety G., Yegani P, Chowdhury K., "Mobility
Management using Proxy Mobile IPv4", Internet-Draft, January
2007.
[3] C. Rigney et al "Remote Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000
[4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997
[5] Perkins C., Calhoun P., "AAA Registration for Mobile IPv4",
Internet-Draft, June 2004
[6] Plummer D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, RFC
826, November 1982
Vamsi & Nazim Expires August 15, 2008 [Page 25]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
[7] Rigney C., Willens S., Rubens A., Simpson W., "Remote
Authentication Dial in User Service (RADIUS)" - RFC2865, June
2000
[8] Kulkarni M., Patel A., Leung K., "Mobile IPv4 Dynamic Home
Agent (HA) Assignment" - RFC4433, March 2006
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[9] Postel J., "Multi-LAN Address Resolution", RFC 925, October
1984
[10] Carl-Mitchell S., Quarterman J., "Using ARP to Implement
Transparent Subnet Gateways", RFC 1027, October 1987
[11] Aboba B., "IANA Considerations for RADIUS" - RFC2869, July
2003
Author's Addresses
Vamsi Krishna Gondi,
LRSM research lab, University of Evry,
Evry, France.
Email: gondi@ensiie.fr
Nazim Agoulmine,
LRSM research lab, University of Evry,
Evry, France.
Email: nazim.agoulmine@iup.univ-evry.fr
Toan TRAN,
Ecole Politechnique, France
Email: khanh.tran@polytechnique.edu
Vamsi & Nazim Expires August 15, 2008 [Page 26]
Internet-Draft AAA and Proxy Mobile IPv4 February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Vamsi & Nazim Expires August 15, 2008 [Page 27]
