Internet Engineering Task Force M. C. Chuah
INTERNET DRAFT Lucent Technologies
Y. Li
Bay Networks, Inc.
30 October 1997
Distributed Registration Extension to Mobile IP
draft-chuahli-mobileip-dremip-00.txt
Status of This Memo
This document is a submission to the Mobile-IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the mobile-ip@smallworks.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document proposes an extension to the Mobile IP base protocol.
The features in this extension allow us to (i) reduce frequent
distant registrations at the mobility agents, (ii) be more scalable
by a separation of registration and forwarding services, (iii) ease
the key management problem among mobility agents, and (iv) be
interoperable with other mobility agents/mobile nodes running
standard Mobile-IP specified in RFC2002.
Expires April 1998 [Page i]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
Contents
Abstract ............................................................ i
1. Introduction ..................................................... 1
1.1. Architectural Entities ..................................... 2
1.3. Terminology ................................................ 2
1.3. Design Goals ............................................... 4
1.3.1 Reduce Distant Registration Frequency ..................... 4
1.3.2 Ease of Key Management .................................... 5
1.3.3 Increase Scalability ...................................... 5
2. Protocol Overview ................................................ 6
2.1. Agent Discovery ............................................ 6
2.2. Local Registration ......................................... 6
2.3. Home Registration .......................................... 7
2.4. Transit Registration ....................................... 7
2.5. Datagram Routing ........................................... 8
2.6. Local/Home Service.......................................... 8
2.7. Foreign Server Smooth Handoffs ............................. 9
2.8. Optimizing Registrations ................................... 9
2.9. Interoperability with the Base Protocol .................... 10
3. Message Formats .................................................. 11
3.1. Agent Advertisement ........................................ 11
3.2. Registration Request ....................................... 11
3.3. Registration Reply ......................................... 12
3.4. Route Request .............................................. 12
3.5. Route Reply ................................................ 13
4. Newly Defined Extensions ......................................... 14
4.1. Registration Server Extension .............................. 14
4.2. Care-of Address Extension .................................. 14
4.3. Agent-Server Authentication Extension ...................... 16
4.4. Mobile-Server Authentication Extension ..................... 16
4.5. Server-Server Authentication Extension ..................... 17
5. Care-of Agent Considerations ..................................... 17
5.1. Receiving Route Request .................................... 17
5.2. Binding Route Enable/Disable................................ 18
6. Registration Server Considerations ............................... 18
6.1. Data Structure ............................................. 19
6.2. Receiving Registration Request as a Binding Registrar ...... 19
6.3. Receiving Registration Request as a Binding Relay .......... 20
6.4. Sending Route Request ...................................... 21
6.5. Receiving Route Reply ...................................... 21
6.6. Load Balancing ............................................. 22
Expires April 1998 [Page ii]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
7. Mobility Agent Considerations .................................... 22
7.1. Sending Agent Advertisement ................................ 22
7.2. Receiving Registration Request as a Foreign Agent .......... 22
7.3. Receiving Registration Request as a Home Agent ............. 22
7.4. Receiving Registration Reply ............................... 22
7.5. Receiving Route Request .................................... 22
8. Mobile Node Considerations ....................................... 23
8.1. Receiving Agent Advertisement .............................. 23
8.2. Sending Registration Request ............................... 23
8.3. Receiving REgistration Reply ............................... 24
8.4. Handoff .................................................... 24
Appendix A Registration Server Discovery Procedure .................. 25
Appendix B Care-of Agent Discovery Procedure ........................ 25
Appendix C Key Distribution Between Registration Servers ............ 25
Appendix D Example Scenarios ........................................ 26
Appendix D.1 Local/Home Registrations ............................... 26
Appendix D.2 Transit/Home Registrations ............................. 27
Appendix D.3 Optimizing Registrations ............................... 31
Appendix D.4 Interoperability with RFC2002 .......................... 32
Reference ........................................................... 33
Acknowledgement ..................................................... 34
Authors's Address ................................................... 34
Expires April 1998 [Page iii]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
1. Introduction
Mobile IP base protocol [1] provides an efficient, scalable mechanism
for node mobility within the Internet. However, the key management
between the home and foreign agents, and between the foreign agents
and the mobile node is still a problem.
Secondly, as Perkins [2] addresses in the hierarchical foreign agents
model, each time the mobile node moves, a Registration Request
message has to be approved by the mobile node's Home Agent. In cases
where the home agent is far away, it may become too expensive or even
impossible to complete these frequent registrations. This document
proposes an extension to the Mobile IP base protocol to solve these
problems.
In this internet draft, we introduce some extensions to the base
protocol to provide a more scalable solution to the mobility
management problem. Our proposed extension separates the the
registration and forwarding services. The registration service can
be provided additionally by a network entity called registration
server while the forwarding service can be provided by a network
entity called care-of agents. The introduction of registration
servers allow us to reduce the number of trusted entities in the
network and hence enable us to ease the key management problem. It
also allows us to do authentications such that illegal use of routing
services. The introduction of care-of agents allow us to do
load-balancing according to the dynamically changing traffic needs.
In addition, we define 3 types of registrations, namely local, home
and transit registrations. By having these different types of
registrations, we are able to reduce the frequency of distant
registrations. Our new features are introduced in such a way that the
mobile nodes and mobility agents supporting our new features can
still interoperate with mobile nodes and mobility agents supporting
the base protocol specified in RFC2002.
Expires April 1998 [Page 1]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
1.1. Architectural Entities
The memo introduces the following new architectural entities:
Registration Server (RS)
An entity providing registration service within a routing
domain. A registration server in the mobile node's home routing
domain is called a Home Registration Server. A registration
server in the routing domain that the mobile node is visiting
is called a Local Registration Server. Otherwise, it is called
a Transit Registration Server.
Care-of Agent (COA)
An entity providing forwarding service and hence care-of
addresses. In the base protocol, a care-of agent is the foreign
agent itself. However, we propose here to separate it from the
foreign agent.
1.2. Terminology
Care-of Address
The care-of address is redefined, in this memo, as an IP
address from which datagrams can be relayed to the mobile
node, whether or not through one or more intermediate nodes.
Mobility Binding
The mobility binding is redefined the same as in the base
protocol except that the care-of address takes the above
definition.
Registration
The registration is redefined as a procedure for mobile node to
register a mobility binding with a registration server or a
home agent and to obtain a care-of address closer to the home
agent, by exchange of Registration Request and Registration
Reply messages. In the base protocol, this is a registration
with a home agent.
The care-of address submitted in the Registration Request is
called the CHILD care-of address of the registration. The one
obtained by this registration is called the PARENT care-of
address of the registration.
Binding Registrar
A registration server or home agent, with which the mobile node
registers a mobility binding. In the base protocol, this is the
home agent, with which a mobility binding is associated.
Expires April 1998 [Page 2]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
Binding Relay
A foreign agent or registration server, through which the
Registration Reply for a mobility binding can be delivered to
the mobile node. In the base protocol, this is the foreign
agent.
A mobile node is allowed to register a mobility binding with a
binding registrar via a binding relay.
Home/Local/Transit Registration
A registration where the binding registrar is in the mobile
node's home routing domain is called a home registration. A
registration where the binding registrar is in the routing
domain that is visited by the mobile node is called a local
registration. Otherwise, the registration is called a transit
registration.
Complete Registration
The combination of one or more registrations, which allows
tunnels to be built such that there will be at least one
forwarding path from the home agent to the visiting mobile
node.
Binding Route Enabled/Disabled
A binding route is enabled by a care-of agent if, a datagram
destined for the mobile node is relayed by this care-of agent
from the parent care-of address of a registration to the child
care-of address. In the base protocol, this means to build a
tunnel from the home agent to the care-of address and to add a
routing entry to the care-of address for the mobile node.
A binding route is disabled by a care-of agent if, the care-of
agent functions as a regular router disregarding the existence
of a mobility binding if any. Thus, a datagram destined for the
mobile node will be forwarded to the mobile node's home network
or simply discarded with an ICMP message bounced if the
datagram was tunneled to the care-of agent.
Expires April 1998 [Page 3]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
1.3 Design Goals
There are 5 major design goals for this protocol, namely,
(i) reduce frequent distant registrations,
(ii) ease key management,
(iii prevent illegal use of routing services,
(iv) increase scalability,
(iv) interoperable with RFC2002.
This protocol separates the the registration and forwarding services.
The registration service is provided by the registration server while
the forwarding service is provided by the care-of agents. Since each
routing domain may only have one registration server and many care-of
agents, the number of trusted entities in mobile networks are reduced
and hence enable us to ease the key management problem. It also
allows us to do authentications such that illegal use of routing
services can be prevented.
1.3.1 Reduce Frequent Distant Registrations
To reduce frequent distant registrations, we define 3 types of
registrations, namely local, home and transit registrations. When the
mobile node moves from one routing domain to another, it needs to
perform a home registration with the home registration server (HRS)
to inform the HRS of the identity of the local Registration Server it
is currently registered.
When the mobile node moves within the same routing domain, even
though its point of attachment may change from one foreign agent to
another, the mobile node only needs to perform local registrations.
As long as the parent care-of address in the local Registration Reply
message matches with the one obtained previously, the mobile node
needs not perform any home registrations. That way, the number of
distant registrations with HRS can be reduced.
The transit registrations are used when the mobile node's home
registration server does not have security association with the
local registration server. The local server will give the mobile
node the identity of a registration server which can act as a
middleman for the home registration. The mobile node will first
perform a transit registration with this transit registration
server to get a parent care-of address. Using this allocated
care-of address from the transit registration, the mobile node
can then do a home registration via the transit registration
server.
Expires April 1998 [Page 4]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
In our proposed registration extension MobileIP protocol, we
assume that the home registration life time exceeds the transit
registration life time which exceeds the local registration life
time.
1.3.2 Ease of Key Management/Prevent Illegal Usage
One of the design goals in this protocol is to prevent replay attacks
in the mobile node's registration procedure, and to prevent an
illegal mobile node from stealing services from a routing domain. The
existing mobile IP base protocol does not require an existence of
security associations between the mobile node and the foreign agent,
and between the home agent and the foreign agent.
If there are already such security associations, this protocol works
exactly the same way as the base protocol. Otherwise, this protocol
provides a means to compensate for a lack of such security
associations. We assume that there are security associations between
registration servers. Since the number of registration servers are
much less than the number of mobility agents, we have a reduction in
key management problem. This makes the our enhanced Mobile-IP model
more scalable.
If there is no security association between the mobile node and the
foreign agent or no security association between the foreign agent
and the home agent, the mobile node will not be allowed to register
directly with its home agent, but to first register with a
registration server in the local routing domain. This local server
in turn allocates a parent care-of address and returns to the mobile
node via the registration reply.
If there is a security association between the foreign server and the
mobile node's home agent, the mobile node can subsequently register
the parent care-of address allocated by the foreign server with the
home agent.
Otherwise, the mobile node is advised to register with its home
registration server via the foreign server. This is feasible because
there are security associations between the foreign server and the
home server, and between the mobile node and the home server. Thus, a
completely secured binding is established, which allows packets to be
delivered to the mobile node.
1.3.3 Increase Scalability
As mentioned above, the introduction of registration servers reduces
the number of trusted entities and hence reduce the severity of key
management problem. Hence, our enhanced Mobile-IP model is more
scalable than the Base protocol. In addition, by separating the
registration service with the forwarding services and introducing
as many care-of agents as we need, we can perform some load-balancing
to cater to the dynamically changing traffic needs.
Expires April 1998 [Page 5]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
2. Protocol Overview
A mobile node should have a complete registration when it moves away
from its home network. A complete registration consists of local
registrations, home registrations and/or transit registrations. A
registration starts with receiving Agent Advertisements. Thus,
changes for this protocol will apply to both the Agent Discovery and
the Registration procedures.
2.1 Agent Discovery
In the base protocol, the foreign agents advertise their presence via
Agent Advertisement messages. The mobile node obtains a care-of
address (which usually is the foreign agent's address) from the
advertisements. The mobile node may initiate a registration using
this care-of address.
In this proposal, the care-of address obtained from the Agent
Advertisement and used in a registration request is referred to
as the child care-of address of this registration.
In addition to the care-of addresses in the Agent Advertisement
message, our proposal requires that the Agent Advertisement
message includes a registration server extension so that
prospective mobile nodes can choose a registration server for the
local registration. The registration extension contains one or more
registration server addresses. There is a priority value and a
lifetime associated with each registration server's address.
2.2 Local Registrations
When the mobile node detects a change in the point of attachment, it
performs a local registration with the local registration server via
a foreign agent. The mobile node sends a Registration Request
message to the local server. The local server replies with a
Registration Reply message. This message contains a parent
care-of address which usually is the IP address of a care-of
agent that has been assigned to provide forwarding service for
the visiting mobile node. One can consider this care-of agent as
the local home agent in terms of forwarding. Note that if the local
registration server happens to be the home agent or
the Home Registration Server of the mobile node, then usually the
care-of agent assigned will be the home agent of the mobile node.
The local server may request the assigned care-of agent to enable the
binding route via an exchange of Route Request and Route Reply
messages with the care-of agent. Thereafter, packets from any node
within the local routing domain may be able to reach the mobile node.
This may additionally require changes to relevant intra-domain
routing protocols, which is beyond the scope of this document.
For any registration, we require that a care-of address, called the
parent care-of address, be returned to the mobile node by
means of the registration reply.
Expires April 1998 [Page 6]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
2.3 Home Registrations
If the parent care-of address obtained via local registration is not
the same as the address of the mobile node's home agent, and the
parent care-of address is also different from that obtained
previously, then, the mobile node should perform home registrations.
The mobile node builds a new mobility binding using this parent
care-of address by registering this binding with its home
registration server, via the local server. The mobile node does so
via an exchange of Registration Request and Registration Reply
message with the home server.
In this home registration, the parent care-of address obtained
through a previous local registration becomes the child care-of
address. The care-of address returned from the home registration
server is a new parent care-of address which usually is the address
of the mobile node's home agent. In this manner, a complete
registration is performed among the mobile node, the foreign agent,
the local server, the home server and the home agent.
The home server may request the home agent to enable the binding
route, that is, to build a tunnel from the new parent care-of
address (the home agent's address) to the child care-of address
(a care-of agent's address at the visiting domain) via an exchange
of Route Request and Route Reply messages.
2.4 Transit Registrations
There are two scenarios where transit registrations may be used.
Type 1 Transit Registrations are used when the mobile node moves
from one routing domain to another and has a valid mobility binding
with a previous foreign server. In this case, the mobile node may
issue a transit registration request to that previous foreign
server to enable a binding route from the previous parent care-of
address to the current one.
Such a mobility binding is transitional and helps to ensure that data
that has been delivered to the previous parent care-of address can be
forwarded to the new parent care-of address. This transitional
binding can be removed once the mobile node has completed its
registration of the new parent care-of address with the home
registration server.
Type 2 Transit Registrations are used when a foreign server in the
visiting domain has no security association with the home server. In
this case, the mobile node may register, via the local server, the
local parent care-of address with a transit registration server,
which in turn allocates a new parent care-of address to the mobile
node. The mobile node then registers, via the transit server, this
new parent care-of address with the home server. It is expected
that the mobile node has security association with the transit
registration server.
Expires April 1998 [Page 7]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
2.5 Datagram Routing
Through a series of local, transit and home registrations, the mobile
node obtains a path from the home agent to the foreign agent. The
path consists of a sequence of tunnels with the starting point of the
first tunnel being the home agent, and the termination point of the
last tunnel being the foreign agent, and each of the tunnels begins
with a parent care-of address and ends with a child care-of address.
Datagrams sent to the mobile node's home address are intercepted
by its home agent, tunnelled from one care-of agent to another until
they reach the foreign agent, and finally being delivered to the
mobile node by the foreign agent.
These tunnels fall into three categories: home tunnels, transit
tunnels, and local tunnels. A home tunnel begins with a home agent or
a care-of agent allocated by a home registration server, and ends
with a care-of agent allocated by another registration server. A
transit tunnel begins with a care-of agent allocated by a transit
registration server and ends with a care-of agent allocated by the
current visiting registration server. A local tunnel begins with a
care-of agent allocated by the current visiting registration server
and ends at the foreign agent. Each of these tunnels is authorised by
two registration servers or by a registration server and a mobility
agent.
In the reverse direction, datagrams sent by the mobile node are
generally delivered to their destination using standard IP routing
mechanisms, not necessarily passing through the care-of agents, the
home or foreign agent.
2.6 Local/Home Service
In some cases, the mobile node may just be interested in
communicating with the hosts in its visiting domain but not
interested in having home traffic forwarded to its visiting
location. For such scenarios, if the visiting network has
pre-arrangement with the mobile node's home registration server
to provide local services to mobile nodes that belong to that
home registration server, then the mobile node only needs to
perform local registration.
Expires April 1998 [Page 8]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
2.7 Foreign Server Smooth Handoffs
When a mobile node moves and discovers that the local
registration server does not change, then it only needs to
perform a local registration.
When a mobile node moves and discovers that the local
registration server has changed, then it not only performs
a local registration, it also performs a home registration.
As in the route optimization draft [6], a Previous Foreign Server
Notification option can be implemented so that the new foreign
server can notify the old foreign server about the mobile node's
new mobility binding. This notification can be used by the
previous server to tear down existing tunnels. Such notification
also allows any datagrams that have been delivered to the
previous care-of agent to be delivered to the new care-of agent.
If the new foreign registration server does not have a security
association with the home registration server, then all 3 types
of registrations, namely local, transit and home registrations
have to be performed.
2.8 Optimizing Registrations
In earlier sections, we describe how DREMIP supports local,
transit and home registrations. In this section, we elaborate
a bit on how a mobile node can combine both the local and home
registrations within one Registration Request message.
A mobile node who wishes to make a local and home registrations
can send a Registration Request message with a registration
server extension. The binding registrar in the Registration
Request message will be the local server and a MN/Local Server
authentication extension can be appended. The Home Registration
Server identity is contained in the Registration
Server Extension. The Mobile Node can also attach the MN/Home
Server Extension at the back of the Registration Server
Extension.
We refer the readers to Appendix D.3 for more details on such
registration optimizations.
In addition, it is a requirement in DREMIP that the following
inequality holds for local, home and transit registration
lifetimes:
Local Registration LifeTimes <= Transit Registration LifeTimes
<= Home Registration LifeTimes
Note also that the lifetimes of the different tunnels: local,
transit and home tunnels can be set according to the local,
transit and home registration lifetimes respsectively. If
the Previous Foreign Agent Notification feature is implemented,
then the tunnel lifetimes can be set to infinity and the
deregistration message can be used to tear down the tunnel.
Expires April 1998 [Page 9]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
2.9 Interoperability with the Base Protocol
To make the this protocol compatible with the base protocol, a few
requirements apply to the mobile node, foreign agent and home agent.
Upon receipt of an Agent Advertisement message without registration
server extension, the mobile node should be able to register with a
home agent via the foreign agent as in the base protocol. In this
case, the mobile node should not check for the presence of any
care-of address extension in the Registration Reply.
In addition, the Registration Request should be sent as a Home
Registration Request. The binding registrar address field should be
the home registration server address or the home agent address. If
there is no security association between the mobile node and the home
agent, but there exists one between the mobile node and the home
server, then the Registration Request should be directed to the home
server.
A home or foreign agent should check the R-bit in the Registration
Request message to determine whether the mobile node is supported by
this protocol. A foreign agent, upon receipt of a Registration
Request with R-Bit cleared, should not require that there be a
mobile-foreign authentication extension in the request and a
foreign-home authentication extension in the further reply message.
In Appendix D.4, we give two example scenarios and explain in
greater details how a mobile node without DREMIP feature can use
the Mobile-IP service in a DREMIP network and how a mobile node
with DREMIP feature can use the Mobile-IP service in a
RFC2002-compliant foreign network.
Expires April 1998 [Page 10]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
3. Message Formats
3.1 Agent Advertisement
The Agent Advertisement messages additionally include a registration
server extension, which contains one or more registration server
addresses. Thus, the mobile node can be informed of the registration
server addresses and register its mobility binding with one of them.
3.2. Registration Request
One bit is added to the Registration Request message to indicate the
registration is supported by this distributed registration extension
protocol. The IP and UDP fields of the Registration Request message
is the same as described in RFC2002. The UDP header is followed by
the Mobile IP fields shown below:
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|V|R|r| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Registrar |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
distributed Registration extension (R):
The R-bit is set by a mobile node or a binding registrar to
indicate that the procedure is supported by this registration
extension protocol. This bit is for the purpose of
interoperability with the base protocol.
Reserved (r):
The r-bit should be set to 0.
Binding Registrar:
A home agent or a registration server.
Expires April 1998 [Page 11]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
3.3. Registration Reply
There is no change in the format of the Registration Reply message
except that, the "Home Agent" field is renamed to "Binding Registrar"
field.
In addition to a few authentication extensions, the Registration
Reply MUST include a care-of address extension so that a
registration server can allocate a parent care-of address to the
mobile node. The Registration Reply MAY additionally appends a
registration server extension to advise the mobile node to choose a
registration server address as the next binding registrar.
3.4. Route Request Message
Route Request is sent by a registration server to a care-of
agent to enable a binding route between the care-of agent and a
child care-of address of a registration.
IP fields:
Source Address Typically the interface address from which
the message is sent.
Destination Address Typically the IP address of the care-of
agent.
UDP fields:
Source Port <variable>
Destination Port 434
The UDP header is followed by the fields shown below:
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 | Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 32 (Route Request)
Reserved sent as zero; ignored on reception.
Lifetime
The number of seconds remaining before the route is
considered expired. A value of zero indicates a request
for disabling. A value of 0xffff indicates infinity.
Destination Address
The home address of the mobile node.
Next Hop Address
The child care-of address of a registration
Identification
A 64-bit number, constructed by the server, used for
matching Route Requests with Route Replies, and for
protecting against replay attacks of these messages.
Extensions
The fixed portion of the Route Request is followed
by one or more of the Extensions.
Expires April 1998 [Page 12]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
3.5. Route Reply Message
The care-of agent returns a Route Reply message to the server which
has sent a Route Request (Section 3.4) message. The Reply message
contains the necessary codes to inform the server about the status
of its request, along with the lifetime granted by the care-of
agent, which MAY be smaller than the original Request.
IP fields:
Source Address Typically copied from the destination
address of the Route Request to which
the care-of agent is replying.
Destination Address Copied from the source address of the
Route Request to which the care-of agent
is replying
UDP fields:
Source Port <variable>
Destination Port Copied from the source port of the
corresponding Route Request
The UDP header is followed by the fields shown below:
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 | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 33 (Route Reply)
Code A value indicating the result of the Route Request.
See below for a list of currently defined Code values.
Lifetime
If the Code field indicates that the care-of agent agrees
to add the route capability, the Lifetime field is set to
the number of seconds remaining before the route is
considered expired. A value of zero indicates that the
route has been disabled. A value of 0xffff indicates
infinity.
If the Code field indicates that the route was denied,
the contents of the Lifetime field are unspecified and
MUST be ignored on reception.
Expires April 1998 [Page 13]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
Destination Address
The home address of the mobile node.
Next Hop Address
The child care-of address of a registration
Identification
A 64-bit number used for matching Route Requests with
Route Replies, and for protecting against replay attacks
of tunnel messages. The value is based on the
Identification field from the Route Request message from
the client.
Extensions
The fixed portion of the Route Reply is followed by one
or more of the Extensions.
The following values are defined for use within the Code field.
0 route added
64 reason unspecified
65 administratively prohibited
67 server failed authentication
68 requested Lifetime too long
69 poorly formed message
Up-to-date values of the Code field are specified in the most recent
"Assigned Numbers" [5].
Expires April 1998 [Page 14]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
4. Newly Defined Extensions
4.1. Registration Server Extension
This extension is placed in the Agent Advertisement message or
Registration Reply message, and is used to provide the mobile node
with addresses of a collection of available registration servers.
Note that we have included a priority level for different
registration servers. One can use this priority level to provide
hierarchical registrations or as an congestion-level indicator to
prevent mobile nodes from registering with an overloaded
registration 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 | Length | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Server Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Server Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 81
Length 2 + 8 * number of registration server addresses
Lifetime
The number of seconds remaining before the registration
server is considered invalid. A value of zero indicates
the registration server doesn't provide service to more
mobile nodes. A value of 0xffff indicates infinity.
Priority
The level of authorization.
4.2. Care-of Address Extension
This extension is placed in the Registration Reply so that a
registration server can allocate a care-of address to the mobile
node.
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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| care-of address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 82
Length 6
Reserved 0
care-of address
parent care-of address or home agent address
Expires April 1998 [Page 15]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
4.3. Agent-Server Authentication Extension
This extension is included in the Registration Request and
Registration Reply messages between the foreign agent and the foreign
registration server, and between the home agent and the home
registration server. The protcol here requires that there exists a
security association between an agent and a registration server in
the same routing domain.
The extension MUST also be included in the Route Request and Route
Reply messages between a registration server and a care-of agent.
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 | Length | SPI ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... SPI (cont.) | Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 83
Length 4 plus the number of bytes in the Authenticator.
SPI Security Parameter Index (4 bytes). An opaque identifier
Authenticator
(variable length)
4.4. Mobile-Server Authentication Extension
This extension is included in the Registration Request and
Registration Reply messages between the mobile node and the foreign
registration server, and between the mobile node and the home
registration server. The protocol here requires that there exists a
security association between a mobile node and a registration server
whether they are in the same routing domain or not.
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 | Length | SPI ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... SPI (cont.) | Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 84
Length 4 plus the number of bytes in the Authenticator.
SPI Security Parameter Index (4 bytes). An opaque identifier
Authenticator
(variable length)
Expires April 1998 [Page 16]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
4.5. Server-Server Authentication Extension
This extension is included in the Registration Request and
Registration Reply messages between two registration servers,
especially between the foreign registration server and the home
registration server. The protocol here requires that there exists a
security association between two registration servers whether they
are in the same routing domain or not.
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 | Length | SPI ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... SPI (cont.) | Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 85
Length 4 plus the number of bytes in the Authenticator
SPI Security Parameter Index (4 bytes). An opaque identifier
Authenticator
(variable length)
5. Care-of Agent Considerations
The care-of agent could be an OSPF area border router, an autonomous
system border router or a backbone router. In the base Mobile-IP
protocol, the care-of address was originally associated with a
foreign agent and a foreign agent has the responsibility of
forwarding the traffic destined to the mobile node. In this
registration extension protocol, the care-of agent is designed to
forward traffic destined to the mobile node.
5.1. Receiving Route Request
Upon receipt of a Route Request, the care-of agent MUST check the
validity of the message. The request is valid if
- the UDP checksum is valid; AND
- the message MUST include an Agent-Server Authentication extension at
the end and the Authenticator is valid.
An invalid request SHOULD be discarded and an error SHOULD be logged.
On receipt of a valid Route Request message, the care-of agent SHOULD
respond with a Route Reply with the lower 32-bit identification
copied from the original request.
If the care-of agent is not able to honor the request, it SHOULD put
a proper code in the reply.
Expires April 1998 [Page 17]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
If the care-of agent denies the request and disable the binding route
to the child care-of address, it SHOULD set the code to a positive
value (0) and the lifetime to 0.
Otherwise, if the care-of agent agrees to enable a binding route to
the child care-of address, it SHOULD set the code to a positive value
(0) and the lifetime to a value not greater than that in the original
Request. The binding route is valid within the granted lifetime and
SHOULD be disabled upon its expiry.
5.2. Binding Route Enable/Disable
In general, a care-of agent MAY enable or disable a binding route
using tunneling mechanism ([4]). Within a routing domain, however,
the care-of agent MAY take advantage of underlying routing protocols
instead. This approach may be discussed elsewhere. In this document,
we assume a care-of agent uses the tunneling mechanism.
To enable a binding route, the care-of agent MAY first build a tunnel
to the next hop address specified in the Route Request message if
such a tunnel does not exist previously. The care-of agent then
installs in its forwarding cache an entry with the tunnel as the
outgoing circuit. To disable the registration delivery, the care-of
agent can simply remove the entry from its forwarding cache. If there
is no entry associated with the tunnel, the care-of agent SHOULD
additionally remove this tunnel.
6. Registration Server Considerations
A registration server MAY not be a router. It is designed to be
independent of the forwarding path for mobile traffic, and to monitor
and switch the forwarding path. A registration server performs local
registrations at most times but less frequently does home and transit
registrations.
The local registration is used to establish the local mobility
binding of a mobile node, that is, the association of the mobile node
with a local registration server, a foreign agent, and the lifetime
of this association. The local mobility binding MAY create the mobile
node's connectivity to the local routing domain.
The local registration server, taking the advantage of the above
local mobility binding, then establishes a home mobility binding,
that is, the association of the mobile node with the home agent or
the home registration server of the mobile node, the local
registration server, and the lifetime of the association.
The registration server MAY be configured with one or more care-of
agent addresses, which are allocated to mobile nodes such that
traffic load can be balanced.
Expires April 1998 [Page 18]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
6.1. Data Structure
For each registration server and each visiting mobile node, there are
generally two registrations: one where the registration server acts
as the binding registrar and the other where the registration server
acts as a binding relay. Each registration creates an entry in the
registration server cache. Since the mobile node may perform mutiple
registrations (home and/or transit) based on an existing local
registration, a registration server SHOULD NOT merge the two entries
into one. The entry created by a local registration where the
registration server is the binding registrar consists of
- mobile node's home address
- child care-of address and
- parent care-of address
- lifetime, and
- the forwarding status over the tunnel between parent and child
care-of address.
Each entry created by the home or transit registration where the
registration server is the binding relay should have a pointer to the
above entry, and additionally includes
- binding registrar, and - lifetime
6.2. Receiving Registration Request as a Binding Registrar
Upon receiving a valid registration request where the registration
server is the binding registrar, the server should check if the
mobile node is previously associated with any care-of agent. If it is
not, the server should choose a parent care-of address. The server
SHOULD exchange a pair of Route Request and Route Reply with the
relevant care-of agent in order for the care-of agent to enable a
binding route for the lifetime requested by the mobile node. The
server SHOULD NOT return Registration Request to the mobile node
until it receives a Route Reply from the care-of agent.
After the server receives a positive Route Reply from the care-of
agent, the server will verify that the tunnel lifetime is
consistent with the registration life time. Then, the server SHOULD
send a positive Registration Reply to the mobile node if there is a
security association between itself and the mobile node. The server
SHOULD deny this request by sending a negative Registration Reply to
the mobile node. In this case, the server SHOULD additionally ask
the care-of agent to disable the binding
route by exchange of negative Route Request and Route Reply.
For this case, if the registration server previously does not have
a mobility binding yet with the mobile node, it SHOULD allocate a
parent care-of address, put it in a care-of address extension, and
append the extension to the Registration Reply. However, if the
registration server has a binding with the mobile node previously,
the old care-of address SHOULD be put in that extension. This
ensures that the mobile node can obtain the same parent care-of
address if repeatedly registering with the registration server.
Expires April 1998 [Page 19]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
The registration server MAY include a registration server extension
in the Registration Reply message for the mobile node to perform
further transit/home registrations.
The registration server SHOULD include an agent-server or server-
server authentication extension in the reply if the binding relay
is the foreign agent or another registration server, respectively.
If there is no tunnel currently between the parent and child care-of
address, the registration server SHOULD direct the care-of agent, by
issuing a Route Request message, to build a tunnel from the parent
care-of address to the child care-of address of the mobile node. The
child care-of address is specified in the Registration Request while
the parent care-of address is allocated by the binding registrar.
If the registration server is a home server, the parent care-of
address it allocates MAY be the home agent address. In this case,
the care-of agent is the home agent.
6.3. Receiving Registration Request as a Binding Relay
Upon receiving a valid registration request where the registration
server is the binding relay, the registration server MUST verify
that there is already an entry for this mobile node where it acts as
a binding registrar. If not, the Registration Request MUST deny this
request. The registration server SHOULD also verify that there is a
security association between itself and the binding registrar. If
not, the server SHOULD deny this request. The binding lifetime SHOULD
not be greater than the one with the current mobility binding where
the registration server acts as a binding registrar. Otherwise, the
server SHOULD deny this request.
If the Registration Request message meets all the requirements above,
the registration server MAY relay this request to the binding
registrar in the same way as the foreign agent deals with the
Registration Request in the base protocol.
The registration server MAY deny the request and include a
registration server extension for the mobile node to perform
a transit registration with another server. The mobile node
can then perform further home registration via this transit
server.
The registration server SHOULD include a server-server authentication
extension in the request to be relayed, or a mobile-server
authentication extension in the reply if the server denies the
request above.
Expires April 1998 [Page 20]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
6.4. Sending Route Request
To ensure the care-of agent can forward traffic to the mobile node,
the server SHOULD send a Route Request to the care-of agent. The
server SHOULD copy lifetime from the Registration Request to the
Route Request.
The server SHOULD retransmit Route Request if it has not received a
matched Route Reply in a reasonable time. Failure in receipt of such
a Route Reply message after a maximum of retransmissions SHOULD be
logged for further administrative option. The server MAY choose
another care-of agent and repeat the procedure above until no
care-of agent is available. In this case, the server SHOULD send a
negative Registration Reply to the mobile node.
The server MUST append an Agent-Server Authentication extension to
the Route Request message. The SOMIP model requires that there be a
security association between the server and the care-of agent.
6.5. Receiving Route Reply
Upon receipt of a Route Reply, the server MUST check the validity of
the message. The reply is valid if
- the UDP checksum is valid;
- the low-order 32 bits of the Identification field in the Route
Reply equals to the low-order 32 bits of the Identification field
in the most recent Route Request sent to the care-of agent; AND
- the reply MUST include a Agent-Server Authentication extension.
If the code field is negative or the lifetime is zero, the server
MUST send a Registration Reply message with a negative code or
lifetime set to 0.
Otherwise, the server must check for consistency between the
tunnel life time and the registration lifetime. If no previous
agent notification feature is implemented, then the tunnel life
time should not exceed the remaining registration life time.
Otherwise, it may be allowed to exceed to reduce the bandwidth
overhead required in refreshing tunnel lifetimes.
Expires April 1998 [Page 21]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
6.6. Load Balancing
Each registration server occasionally probes their care-of agents on
the traffic load that each of them is supporting. The care-of agents
each return a metric that has a higher value when the traffic load is
higher. Based on such replies, the server can order the list of
care-of addresses with the least loaded one being at the top of the
list. When the server receives a local registration request, it
assigns the least loaded care-of address to that request.
7. Mobility Agent Considerations
7.1 Sending Agent Advertisement
A mobility agent SHOULD include a registration server extension in
the Agent Advertisements. This can facilitate the mobile node in
finding a registration server with whom it has security association
for subsequent registrations.
7.2. Receiving Registration Request As a Foreign Agent
Upon receiving a Registration Request, a foreign agent SHOULD verify
that there is a security association between itself and the binding
registrar. If there is, the agent works exactly the same as the
foreign agent in the base protocol.
Otherwise, the agent SHOULD deny the Registration Request. The agent
MAY include a registration server extension in the Registration Reply
message for the mobile node to choose another binding registrar and
to perform further registrations.
7.3. Receiving Registration Request as a Home Agent
The home agent deals with a received Registration Request in the same
way as the home agent in the base protocol.
7.4. Receiving Registration Reply
The mobility agent deals with a received Registration Reply in the
same way as in the base protocol.
7.5. Receiving Route Request
The foreign agent SHOULD disregard this message.
The home agent SHOULD deal with the Route Request in the same way as
the care-of agent. The home agent SHOULD additionally send proxy ARP
and gratuitous ARP on the home network. The procedure SHOULD be the
same as in the base protocol.
Expires April 1998 [Page 22]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
8. Mobile Node Considerations
8.1. Receiving Agent Advertisement
When a mobile node receives an agent advertisement, it SHOULD check
to see if the mobility agent is its home agent. If it is, it does
nothing since it is at home. Otherwise, it checks to see if there is
a registration server extension in the agent advertisement. If yes,
the mobile node SHOULD choose one of the registration servers whose
addresses appear in the registration server extension and perform a
local registration with the selected server. Note that if the
mobile node is in its home domain i.e. the home registration
server appears in the registration server extension, then the
mobile node SHOULD choose its home registration server.
8.2 Sending Registration Request
The mobile node SHOULD choose a proper binding relay and a binding
registrar from previously received Agent Advertisement messages.
For local registrations, the binding relay is the foreign agent, and
the binding registrar is one of the local registration servers whose
addresses appear in the registration server extension. Note that
if the mobile node is in its home domain, then the binding
registrar that the mobile node chooses SHOULD be its home
registration server.
For the case where the mobile node is visiting a foreign network,
the mobile node will use the local registration
server as the binding relay and the home registration server as
the binding registrar in the mobile node's home registration
request.
For transit registrations, the binding registrar is a registration
server with whom the mobile node has previously established a
mobility binding or with whom the mobile node has a security
association, while the binding relay could be a foreign agent or
another registration server.
If the mobile node previously receives a negative Registration Reply,
which includes a registration server extension, it SHOULD choose a
proper binding registrar to proceed further registration.
The mobile node SHOULD include a mobile-server authentication
extension in the request if the binding relay is a registration
server.
Expires April 1998 [Page 23]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
8.3 Receiving Registration Reply
Upon receiving a valid local registration reply, the mobile node
SHOULD check to see if the binding registrar or the parent care-of
address returned in the reply is its home agent. If yes, this is a
complete registration. If it is not, however, the mobile node SHOULD
check to see if it has previously established a mobility binding with
its home registration server or home agent, using this parent care-of
address.
If it has, nothing needs to be done since the mobile node just
changes its point of attachment locally. Otherwise, the mobile node
SHOULD perform a home registration using this parent care-of address.
In this second registration, the local server will be used as the
binding relay and the binding registrar will be set to the home
registration server's address. The mobile node SHOULD make sure
that the home registration life time exceeds the local
registration life time.
If the reply includes a registration server extension, it means the
the binding registrar advises the mobile node to perform further
registration with one of the registration servers in the extension.
In this case, the mobile node SHOULD choose one of them and proceed
with a registration with the local server set to the binding relay,
and the selected registration server set to the binding registrar.
Again, the mobile node SHOULD make sure that the transit
registration life time exceeds the local registration lifetime.
Later, if the mobile node needs to perform home registration, the
mobile node SHOULD make sure that the home registration lifetime
exceeds the transit registration lifetime.
8.4. Handoff
When a mobile node moves from one foreign routing domain to another,
the mobile node performs a local registration with the new local
server. Then, it can first do a transit registration with its
previous foreign registration server such that a tunnel can be built
from the previous foreign server's care-of address to the new local
server's care-of address. This tunnel is a transitional tunnel that
enables the forwarding of packets that have been sent to the previous
foreign server but have not been delivered to the mobile node. Later,
it performs a home registration with its home registration server
using the new local server's care of address. After establishing a
complete binding with the home registration server, the transitional
tunnel can be torn down.
Expires April 1998 [Page 24]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
Appendix A Registration Server Discovery Procedures
Here, we describe a procedure for mobility agents to discover the
registration servers. We assume that a multicast address has been
assigned to all registration servers. A mobility agent merely needs
to send a Neighbor Request message to the multicast address of the
registration servers. All registration servers that can hear this
Neighbor Request message will respond with a unicast Neighbor Reply
message. The Neighbor Reply message contains a priority level
field. The mobility agent then puts the addresses of all
registration servers and their associated priority levels in the
Agent Advertisement messages that it broadcasts.
The Neighbor Request message can be repeated periodically with
a period long enough to limit the overhead bandwidth consumption.
Details of this registration server discovery procedure will be
provided in another upcoming internet draft.
Appendix B Care-of Agent Discovery Procedures
In practice, we may just manually configure care-of agents.
However, when there are a lot of care-of agents available and
more than one registration servers exist, we may want a more dynamic
assignment of care-of agents to registration servers.
Here, we describe a procedure for registration servers to discover
the presence of care-of agents in its vicinity. Again, we assume
that a multicast address is defined for registration server and
all care-of agents in a routing domain. The registration server
can send a Care-of Agent Solicit message to that multicast
address. All care-of agents that can hear this Care-of Agent
Solicit message will have to respond to the Registration Server
with a unicast Care-of Agent Advertisement message.
Appendix C Key Distribution between Registration Servers
We assume that all cooperating registration servers share a public
key and has a private key. We can use the same approach discussed in
[6].
Expires April 1998 [Page 25]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
Appendix D Example Scenarios
This section shows example Registration Requests for several common
scenarios.
D.1 Local/Home Registrations
D.1.1 Local Registration
The mobile node receives an Agent Advertisement from a foreign agent
which has a registration server extension showing RS2 as the local
registration server. Assume that the mobile node has a security
association with RS2. The mobile node wishes to register with that
agent using the advertised foreign agent care-of address. The mobile
node wishes only IP-in-IP encapsulation, does not want broadcasts,
does not want simultaneous mobility bindings:
IP fields:
Source Address = mobile node's home address
Destination Address = copied from IP source address of the
Agent Advertisement
Time to Live = 1 (?)
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0, B=0, D=0, M=0,G=0, R=1
Lifetime= the Registration Lifetime copied from the Mobility
Agent Advertisement Extension of the Router Advertisement
message
Home Address = the mobile node's home address
Binding Registrar = IP address of RS2 copied from Registration
Server extension
Care-of Address = the Care-of Address copied from the Mobility
Agent Advertisement Extension of the Router Advertisement
message
Identification = Network Time Protocol timestamp or Nonce
Extensions:
The Mobile-Foreign(RS2) Authentication Extension
The Mobile-Agent Authentication Extension (?)
The foreign agent will relay the Registration Request to RS2.
The mobile node upon hearing a positive registration reply from
RS2 (which is relayed by the foreign agent) will copy the parent
care-of address (COA1) allocated from the Care-of Address Extension
in the Registration Reply. The mobile node will create an
entry to record the local registration server's IP address, the
parent care-of address, and the local registration life time.
If we allow for local service and that the foreign network prefers a
tunnel to be built between the care-of agent and the foreign agent
for routing mobile node's traffic packets, then RS2 will direct the
care-of agent whose IP address is the parent care-of address (COA1) to
build a tunnel to the foreign agent.
Expires April 1998 [Page 26]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
D.1.2 Home Registration
Then, the mobile node will send another Registration Request
IP fields:
Source Address = mobile node's home address
Destination Address = RS2's IP address
Time to Live = 1 (?)
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0, B=0, D=0, M=0,G=0, R=1
Lifetime= Oxffff
Home Address = the mobile node's home address
Binding Registrar = MN's Home Server (RS1) 's IP address
Care-of Address = the allocated parent care-of address extracted
from the Care-of Address extension in the Local Registration
Reply.
Identification = Network Time Protocol timestamp or Nonce
Extensions:
The Mobile-Home (RS1) Authentication Extension
The Mobile-Foreign(RS2) Authentication Extension
The local server, RS2, will relay the Home Registration Request to the
MN's Home Server (RS1) by adding the Server (RS2)-Server (RS1)
Authentication Extension. The MN's Home Server will check for the
validity of the Registration Request and sends a Registration Reply
via the local server to the mobile node. The Registration Reply will
contain the MN/Home Server Authentication Extension and the
Server/Server Authentication Extension. If the Home Server approves the
home registration, then the Home Registration Reply
will contain a Care-of Address extension that gives the home agent's
IP address as the parent care-of address. The Home Server
will direct the home agent to build a tunnel to COA1. The Home
Server does so by sending a Route Request Message with Server/Agent
Authentication Extension (if the Home Server does not trust the Home
Expires April 1998 [Page 27]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
D.2 Transit/Home Registration
D.2.1 Transit Registration
Assume that RS2 does not have any server/server authentication with
RS1 in Example D.1.2 above. Then, RS2 will reject the Home
Registration Request and attaches a Registration Server Extension in
its reply:
Registration Reply from RS2 will be as follows:
IP fields:
Source Address = copied from destination address of the
Registration Request to which RS2 is replying
Destination Address = copied from the source address of the
Registration Request to which RS2 is replying
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 3
Code = 67
Lifetime= ignored
Home Address = the mobile node's home address
Binding Registrar = MN's Home Server (RS1) 's IP address
Identification = copied from Registration Request message
Extensions:
Registration Server Extension which gives RS3 as the
transit registration server.
The Mobile-Home (RS1) Authentication Extension
The Mobile-Foreign(RS2) Authentication Extension
Expires April 1998 [Page 28]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
The mobile node will then send a Registration Request with
RS3 as the binding registrar.
IP fields:
Source Address = mobile node's home address
Destination Address = RS2's IP address
Time to Live = 1 (?)
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0, B=0, D=0, M=0,G=0, R=1
Lifetime= Oxffff
Home Address = the mobile node's home address
Binding Registrar = RS3's IP address
Care-of Address = the allocated parent care-of address extracted
from the Care-of Address extension in the Local Registration
Reply.
Identification = Network Time Protocol timestamp or Nonce
Extensions:
The Mobile-Home (RS1) Authentication Extension
The Mobile-Foreign(RS3) Authentication Extension
The Mobile-Foreign(RS2) Authentication Extension
The local server, RS2, will relay the Transit Registration Request to
RS3. RS3 will validate the Registration Request and sends a
Registration Reply to MN. If RS3 approves the transit registration,
it will attach a Care-of Address extension which contains information
on the new parent care-of address (COA2).
Expires April 1998 [Page 29]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
D.2.2 Home Registration
The mobile node then sends a Home Registration Request to its
Home Server via RS3
IP fields:
Source Address = mobile node's home address
Destination Address = RS3's IP address
Time to Live = 1 (?)
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0, B=0, D=0, M=0,G=0, R=1
Lifetime= Oxffff
Home Address = the mobile node's home address
Binding Registrar = MN's Home Server
Care-of Address = the allocated parent care-of address, COA2
extracted from the Care-of Address extension in the Transit
Registration Reply.
Identification = Network Time Protocol timestamp or Nonce
Extensions:
The Mobile-Home (RS1) Authentication Extension
The Mobile-Foreign(RS3) Authentication Extension
If the Home Server approves the registration, it will send
a Registration Reply with an attached Care-of Address Registration
that gives home agent address as the parent care-of address.
The Home Server will also instruct the Home Agent to build a tunnel
to COA2. When RS3 receives the Registration Reply, it will also
instruct COA2 to build a tunnel to COA1. If local service is not
provided by the local server, then we can let transit server
notifies the local server upon successful home registration and the
local server can then instruct COA1 to build a tunnel to the foreign
agent.
Expires April 1998 [Page 30]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
D.3 Optimizing Registrations
Based on the examples described above, we describe in this section
how the number of registrations can be reduced.
D.3.1 Local/Home Registration
With the requirement that the Agent Advertisement contains
all registration servers' addresses that the local server has
authentication with, a mobile node can decide if it can perform
a home registration together with a local registration.
If the mobile node finds its Home Server's address in the
Agent Advertisement, it can send a Registration Request
Message with an attached Registration Server Extension
which contains the Home Server address and its life time.
IP fields:
Source Address = mobile node's home address
Destination Address = foreign agent's IP address
Time to Live = 1 (?)
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0, B=0, D=0, M=0,G=0, R=1
Lifetime= LifeTime copied from Agent Advertisement
Home Address = the mobile node's home address
Binding Registrar = local server (RS2)'s IP address
Care-of Address = foregin agent address
Identification = Network Time Protocol timestamp or Nonce
Extensions:
The Registration Server Extension with Home Server
information and Home Registration Lifetime
The Mobile-Home (RS1) Authentication Extension
The Mobile-Agent Authentication Extension(?)
The Mobile-Foreign(RS2) Authentication Extension
If the local server RS2 approves the registration, it will
change the binding registrar to the Home Server's IP address
(extracted from Registration Server Extension), replaces
the Lifetime with Home Registration Lifetime, and change the care-of
address to a newly allocated parent care-of address. Then, it relay
this registration request message (without the registration server
extension) to the Home Server. Upon receiving a reply from
the Home Server, the local server formulates the following
Registration Reply:
IP fields:
Source Address = copied from destination address of the
Registration Request to which RS2 is replying
Destination Address = copied from the source address of the
Registration Request to which RS2 is replying
UDP fields:
Source Port = <any>
Destination Port = 434
Expires April 1998 [Page 31]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
Registration Request fields:
Type = 3
Code =
Lifetime= Local Registration LifeTime
Home Address = the mobile node's home address
Binding Registrar = RS2's IP address
Identification = copied from Registration Request message
Extensions:
Registration Server Extension which gives Home Server's
IP address as well as Home Registration LifeTime
The Mobile-Home (RS1) Authentication Extension
The Mobile-Foreign(RS2) Authentication Extension
Similar optimizations can be done for the case of transit
registrations.
D.4 Interoperability with RFC2002
D.4.1 Mobile Node with DREMIP feature in a RFC2002-compliant
network
Assume that MN1 which has DREMIP feature visits a foreign network
that runs RFC2002-compliant base Mobile-IP protocol. MN1 receives
an Agent Advertisement without Registration Server Extension. Hence,
it issues a Registration Request Message with R bit cleared to its
Home Agent/Home Registration Server via the Foreign Agent. The
Registration Request Message will not have a Registration Server
Extension. To the foreign agent, the binding registrar's field is
like the Home Agent field in the base protocol. MN1 attaches the
MN/Server or MN/Home Agent Authentication extension. If there exists
authentication extension between MN1 and the Foreign Agent,
MN1 will also attach that extension. The Foreign Agent will
then deliver the Registration Request to the binding registrar
which can either be the Home Registration Server or Home Agent.
If the binding registrar is the Home Registration Server (HRS), then
the HRS will issue a Registration Reply which has the MN's home
address and its home agent address just like in base Mobile-IP
protocol without attaching any Care-of Address extension.
Expires April 1998 [Page 32]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
D.4.2 Mobile Node without DREMIP feature in a DREMIP compliant
network
The mobile node will ignore the registration server extension in the
Agent Advertisement. The mobile node will issue a Registration
Request with R bit cleared to the foreign agent. The Registration
Request contains the MN's home address and MN's home agent address.
The mobile node attaches the MN/Home Agent Authentication
and the MN/Foreign Agent Authentication extensions. Note that here,
we assume that unless there is a MN/Foreign Agent Authentication
extensions, the mobile node cannot use the service in this foreign
network. The foreign agent in the DREMIP network notices that the
R-bit is clear and hence just relays the Registration Request message
to the MN's Home Agent. The Home Agent issues a Registration Reply which
doesn't contain Care-of-Address extension to the Foreign Agent.
The Foreign Agent faithfully delivers the Registration Reply message
to the mobile node.
References
[1] Charles Perkins, editor. IP mobility support. RFC 2002, Oct
1996.
[2] Charles Perkins. Mobile-IP Local Registration with
Hierarchical Foreign Agents. Internet Draft,
draft-perkins-mobileip-hierfa-00.txt, February 1996. Work in
progress.
[3] Charles Perkins. IP Encapsulation within IP. RFC 2003,
October 1996.
[4] David B. Johnson and Charles Perkins. Route Optimization in
Mobile IP. Internet Draft, draft-ietf-mobileip-optim-04.txt,
February 1996. Work in progress.
[5] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700,
October 1994.
[6] J. Zao, etc. A Public-Key Based Secure Mobile IP, Proceedings
of Mobicom97, October, 1997.
[7] D. Johnson, etc. Route Optimizations in Mobile-IP networks
Internet Draft. draft-optim-05.txt, October, 1997. Work in
progress.
Expires April 1998 [Page 33]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997
Acknowledgement
The authors wish to thank Week Tuck Teo from National University of
Singapore for some useful comments on an earlier draft.
Authors' Address
Questions about this memo can also be directed to:
M. C. Chuah,
Performance Analysis Department,
Room 3K-320,
Bell Laboratories,
Lucent Technologies,
101, Crawfords Corner Road,
Holmdel, NJ 07733, USA.
Phone: 732-949-7206
Fax: 732-834-5906
Email: chuah@lucent.com
Y. Li
Protocol Development Group
Engineering Department
Bay Networks, Inc.
BL60-304, 600 Technology Park Drive
Billerica, MA 01821
Phone: (508) 916-1130
Fax: (508) 670-8760
Email: yli@BayNetworks.COM
Expires April 1998 [Page 34]
Internet Draft Dynamic Registration Extension of Mobile-IP 30 Oct 1997