Internet Engineering Task Force S. Glass
INTERNET DRAFT Sun Microsystems
Individual Submission 14 July 2000
Registration Revocation for Mobile IP
draft-glass-mobileip-reg-revok-00.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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@STANDARDS.NORTELNETWORKS.COM mailing list.
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.
Distribution of this memo is unlimited.
Abstract
During the original design of Mobile IP, the potential need for an
administrative domain to be able to actively revoke a current Mobile
IP registration was recognized. Due to the lack of a specific
scenario requiring such a mechanism, it was decided that a passive
mechanism, namely short registration lifetimes, and the denial of a
subsequent registration from a MN, would be sufficient for this
purpose.
Recent investigations into requirements for a AAA protocol has
forced a reconsideration of a more active Mobile IP registration
revocation feature to not only terminate a MN's current registraion,
but to provide a way to inform the other end of the tunnel when all
future registrations are revoked, and to also at least inform a MN
that it's current registration has been revoked. In some cases the
current registration may be terminated to simply force the MN to
renegotiate its registration, and in other cases the registration is
terminated absolutely with no renegotiation allowed by the terminating
Glass Expires 14 January 2001 [Page 1]
Internet Draft Registration Revocation for Mobile IP 14 July 2000
side. What is obvious from this is revocation is be possible from
either home or foriegn agents, so any registration revocation being
defined must also allow signaling to the agent at the other end of the
tunnel that the current registration has been revoked.
This document defines a general use registration revocation
mechanism to meet these requirements.
1. Introduction
During the original design of Mobile IP, the potential was
recognized for one administrative domain to cancel a current mobile
node registration. Due to the lack of specific need for such a
mechanism, it was decided that a passive mechanism, namely the denial
of a subsequent registration from a MN, could be used for this
purpose. Recently, investigating requirements for a AAA protocol has
forced reconsideration of a more active mobile IP feature to not only
cancel a MN's current registraion, and to also allow a MN to be
informed that it's current registration has been revoked.
A general registration revocation mechanism is defined to handle
these situations. The protocol is broken into two disjoint pieces.
First, a mechanism to inform the mobile node of the revocation of it's
current binding is described using a mechanism which already exists in
the base protocol [1]. This means any mobile node which complies with
[1] will understand it's registration has been revoked. Next, a
signaling mechanism between home and horeign agents is described which
allows either the home agent, or foreign agent to initiate the
registration revocation, and to inform the agent at the other end of
the tunnel to tear down the current tunnel, and allow it to free up
resources. In addition, revocation messages pass information between
the agents as to whether the registration is revoked conditionally, or
absolutely. A conditional revocation means the MN's current
registration is terminated, but may be renegotiated in subsequent
reregistration attempts. An absolute revocation, as the name implies,
means the mobile node's current registration is terminated and no
renegotiation [through the current FA] is allowed. These messages are
a logical addition to the group defined in [1] for the generic mobile
IP registration processing.
The methods described in [1] for deregistrations apply to
situations where the mobile node is playing the active roll in
informing the home agent of its location, and maintaining its care-of
address(es). This document describes methods to be used only when the
mobility agents are initiating the revocation of individual bindings
for specific mobile nodes.
This reader is assumed to be familiar with the concepts and
terminology used in [1]. Knowledge of the concepts of [2] and [3] may
also be beneficial.
Glass Expires 14 January 2001 [Page 2]
Internet Draft Registration Revocation for Mobile IP 14 July 2000
2. Motivation
Mobile IP [1] [3] defines registration of a mobile node's location
to permit connectivity between the mobile node and its home domain,
permiting communication between a mobile node and any correspondant
node. At any time the home or foreign agent MAY stop servicing a
mobile node, but no mechanism is described to inform the other end of
the tunnel that service is being terminated. If the HA shuts down the
tunnel, the FA will simply stop seeing tunnel packets for the MN, just
as if a route stopped functioning, or if there is simply nothing being
sent to the mobile node. If the FA shuts down the tunnel, the HA will
continue to send tunnel packets, which will likely be silently
discarded. An aware mobile node may notice the lack of response to
packets it is generating, eventually figure it's binding has vanished
for one reason or another, and may attempt to reregister. When the MN
attempts to reregister its binding, only at that time can it get a
registration denied error with some hint as to why it service was
stopped, by whom, then attempt to renegotiate. Clearly a more active
mechanism should be designed.
3. Registration Revocation Details
Registration revocation consists of two disjoint pieces, a
signalling mechanism between the tunnel endpoints, and a signalling
mechanism between the foreign agent and mobile node. A colocated
mobile node, that is one which is decapsulating it's own tunnel
traffic, MAY implement the tunnel endpoint-signaling portion of this
protocol so that its home agent may signal it if it's binding is being
terminated.
3.1 Foreign Agent Notification to the Mobie Node
A mechanism providing a foreign agent a way to activly notify a
mobile node that its binding has been reset already exists in [1],
though it has been mainly overlooked. As described by [1], when a
foreign agent begins sending agent advertisements, it starts with a
sequence number of 0, and increments this sequence number with each
subsequent agent advertisement. Instead off allowing the sequence
number to roll-over, it is instead set to 256 so a mobile node can
distinguish between a foreign agent state-reset from a rolled-over
sequence number. Leveraging this mechanism, though unspecified
explicity by [1], a foreign agent may notify all mobile node's
currently bound to it that it is resetting all their bindings by
simply resetting its sequence number to 0 (or anywhere in the range 0
- 255 inclusive), even if the agent itself has not been reset.
Moreover, a foreign agent may inform all mobile nodes currently bound
to it to reregister with a different foreign agent by simultaneously
setting the 'B' bit to 1 in such an agent advertisement where the
sequence number has been reset to 0 (or anywhere in the range 0 - 255
inclusive). In these situations, any mobile node in compliance with
[1] understands the FA has lost their binding, and MUST reregister if
they wish to reestablish the tunnels with their home agent.
Glass Expires 14 January 2001 [Page 3]
Internet Draft Registration Revocation for Mobile IP 14 July 2000
By using this mechanism actively, a foreign agent may also notify
a single mobile node that it's binding has been reset by unicasting to
it an agent advertisement with the sequence number set to 0. If such
a foreign agent wishes to indicate to the mobile node that it is to
not attempt to refresh it's registration with it, it may also set the
'B' bit to 1. Note that such a foreign agent is likely to not be
advertising with the 'B' bit set to 1 in its multicast/broadcast agent
advertisements, so other mobile node's will still register with it.
If upon hearing the multicast agent advertisement, should a mobile
node that has recently had it's registration revoked by this FA
attempt to [re]register with it, the agent can simply deny the MN with
an appropriate error code. At this time, the mobile node SHOULD use
foreign agent fallback to attempt to register with a different agent.
If the mobile node decides to send an agent solicitation, this foreign
agent MAY again unicast its agent advertisement to the mobile node
with the 'B' bit set to 1 indicating the mobile node should not
register with it, or alternatively, this foreign agent MAY ignore the
mobile node's agent solicitation.
Agent Advertisements unicast to a mobile node MUST be sent as
described in [1]. This includes any methods currently in use on the
link to make them secure or authenticatable by the mobile node.
3.2 Mobility Agent Registration Revocation Signalling Mechanism
Any active mechanism designed to be useful to both home and foreign
domains must contain a way for either side to revoke the current
binding, and securely inform the other domain of its intension.
In the case where the foreign domain is revoking a mobile node's
binding, the foreign agent SHOULD notify the mobile node as described
in section 3.1 above. In addtion, an FA which is terminating the
binding of a mobile node SHOULD inform the mobile node's current home
agent that it is shutting-down the tunnel exit point. This will allow
the home agent to stop generating tunnel packets for the mobile node,
and also allow it to free resourses it is currently reserving for the
mobile node. In this case an foreign-home security association MUST
exist, and must be included in the registration revocation message.
Upon receiving a registration revocation message the home agent MUST
check the foreign-home authenticator, and if the packet passes the
authentication, MAY free up any resources associated with the former
binding. If a home agent receives a registration revocation message
that does not contain a foreign-home authenticator, it MUST be
ignored.
In the case where the home agent is revoking a mobile node's
binding, the home agent SHOULD notify the care-of address it is
terminating the tunnel entry point. If the mobile node is not
colocated (as indicated to the HA by the setting of the 'D' bit in its
registration request) a home-foreign security association must exist,
and MUST be included in the registration revocation message. Upon
receiving such a notification, the foreign agent MUST check the
home-foreign authenticator, and if the packet passes the
Glass Expires 14 January 2001 [Page 4]
Internet Draft Registration Revocation for Mobile IP 14 July 2000
authentication, the foreign agent SHOULD notify the mobile node that
its binding has been reset by using the method described in section
3.1 above, and MAY free up any resources being used by the former
binding. If a foreign agent receives a registration revocation
message that does not contain a home-foreign authenticator, it MUST be
ignored. If the home agent is revoking the registration of a mobile
node which is colocated, a mobile-home autenticator MUST be used.
Upon receiving such a notification, the mobile node MUST check the
mobile-home authenticator, and if the packet passes authentication,
the mobile node MUST terminate any reverse tunnel encapsulation it is
using to the home agent. The mobile node may also optionally free up
any other resources associated with the former binding.
The case where a colocated mobile node is registered directly with
it's home agent, and wishes to terminate it's own binding is
considered unnecessary. In this case the mobile node MAY simply
deregsiter with its home agent as described by [1] [3]. A foreign
agent advertising the 'R' bit, however, causes a colocated mobile node
to register it's colocated address as its care-of address, which is
the tunnel exit point. In this case, a foreign agent is capable of
revocing the mobile node's registration (as it is privy to the
information in the registration request, namely the mobile node's home
address, and the address of the mobile node's home agent) by sending a
Registration Revocation to either home agent, or mobile node, or by
simply unicasting an agent advertisement with a sequence number of 0
to the mobile node, indicating it's visitor list entry for the mobile
node is gone. In the situation where the foreign agent chooses to use
a Registration Revocation message, a foreign-home or foreign-mobile
security association MUST exist for the registration revocation to be
successful. If one does not exist, the foreign agent MAY deny the
original registration request using the usual registration reply
mecanism described in [1]. In addition, a colocated mobile node that
has had it's registration revoked by such a foreign agent MAY notify
it's home agent by either deregistering directly, but as this may
fail, MAY opt instead to attempt to send a registration revocation
message (via any foreign agent as all foreign agents on a link are
required to all advertise the same setting for the "R" bit) to its
home agent. In this scenario, a mobile-home authenticator MUST be
included in the registration revocation message.
3.3 Registration Revocation Message Format
This section details the format of the signalling protocol between
home and foreign agent, or between home agent and colocated mobile node.
The format of a registration revocation message nearly identical to
registration request and registration request messages.
Glass Expires 14 January 2001 [Page 5]
Internet Draft Registration Revocation for Mobile IP 14 July 2000
IP fields:
Source Address In the case of the home agent issuing the
Registration Revocation, the address
registered with the care-of address as
that of the home agent. In the case of
the foreign agent issuing the
registration revocation, the address
registered with the home agent as the
care-of address.
Destination Address In the case of the home agent issuing the
registration revocation, that of the
care-of addressed registered by the
mobile node whose registration is being
revoked. In the case of the foreign
agent issuing the registration
revocation, the home agent address
registered by the mobile node whose
registration is being revoked.
UDP fields:
Source Port 434
Destination Port 434
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 | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-+-+-
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-
Type 7 (Registration Revocation) (T.B.A.)
Code A value indicating the desired 'level' of Registration
Revocation. See below for a list of currently defined
code values.
Glass Expires 14 January 2001 [Page 6]
Internet Draft Registration Revocation for Mobile IP 14 July 2000
Lifetime
The amount of time the mobile node is to be denied
reregistration. That is, the lifetime of the
registration revocation. A value of zero indicates the
mobile node's current registration is terminated, but
may be allowed reregistration attempts immediately. A
value of 0xffff indicates the current registration is
revoked for an infinite time, and no further
reregistration attempts will be accepted.
Home Address
The IP address of the mobile node whose registration is
being revoked.
Home Agent
The IP address of the Home Agent, namely the tunnel
entry point, or the zero address (see below)
Care-of Address
The IP address serving as the tunnel exit point, or the
zero address (see below).
Identification
A 32-bit number used for protecting against replay
attacks. See section 6 (below).
Extensions
Any relavent extensions for this registration
revocation. e.g. Vendor-specific extensions.
Authenticator
An authenticator as defined in [1] MUST be present.
This is usually in the form of an HA-FA authenticator,
or a HA-MN authenticator when the mobile node is using
a colocated care-of address.
3.4 Protocol Details
A foreign-home authenticator MUST follow any Registration
Revocation message whenever a home agent is performing a Registration
Revocation, and sending this message to a foreign agent, or whenever a
foreign agent is initiating the registration revocation, and sending
this message to a home agent. A mobile-home authenticator MUST appear
if a home agent is sending this message to a colocated mobile node
which is serving as its own tunnel-exit point, or when a mobile node
is notifying its home agent that the local domain has issued a
registration revocation (in this latter case, the mobile node MAY
instead/also attempt to issue a deregistration request as defined in
[1]).
Registration Revocation messages MUST be sent from the source
address of one end of the tunnel, that is from the Care-of address
being used by the mobile node whose home address appears in the
Glass Expires 14 January 2001 [Page 7]
Internet Draft Registration Revocation for Mobile IP 14 July 2000
message, or from the address of the address of the home agent being
used by the mobile node whose home address appears in the same
message. In this way, the agent receiving this message can uniquely
identify which mobile node's binding is to be revoked even in the case
of overlapping privately addressed mobile nodes.
If a home agent is revocing a specific registration for a mobile
node, it MUST include it's own address (a.k.a. the tunnel entry
point), the mobile node's home address, and the registered care-of
address (a.k.a. the tunnel exit point). If a home agent is revoking
all of a particular mobile node's binding with a foreign agent, it
MUST include it's own address (a.k.a. the tunnel entry point), the
mobile node's addres, and it MAY set the care-of address to the zero
address indicating "all bindings for this mobile node." If the home
agent wishes to have the foreign agent revoke all mobile node bindings
that use it as a home agent, it MAY set the home address field to the
zero address. The home agent MUST NOT set the home agent field to the
zero address. If a foreign agent receives a registration revocation
message with the home agent field set to the zero addressm it MUST be
silently ignored. This is to prevent confusion in the case of
overlapping private addresses; when multiple mobile nodes are
registered via the same care-of address using the same
(disparate/private) home address, the home agent address is the only
way a foreign agent can discern these mobile nodes.
If a foreign agent is revocing a specific registration for a
mobile node, it MUST include the registered care-of address, the home
address of the mobile node whose registration is being revoked, and
the home agent address of the current binding. If a foreign agent is
revoking the bindings of all mobile nodes using a particular home
agent, it MAY set the home address field to the zero address. If a
foreign agent is revoking multiple care-of address bindings for the
same mobile node, it MAY set the care-of address to the zero address.
However, if a home agent receives a registration revocation from a
foreign agent indicating the registration for a colocated mobile node
has been revoked, the home agent MUST verify this message is comming
from the same foreign agent that relayed the registration request for
this binding. If this can not be verified, or it can be determined
that the foreign agent issuing this registration revocation is not the
foreign agent which relayed the registration request for the current
binding, the home agent MUST silently ignore it. This means if a
mobile node has one or more bindings with different colocated care-of
addresses, and in addition has one or more bindings using foreign
agent provided care-of addresses (as in the case of multi-homed
foreign agent), each set of bindings must be revoked separately.
3.4.1 Revocation Codes
The registration revocation message contains a code. This is used
to indicate the "severity" of the revocation. In all cases, the
revocation message indicates the current binding has been lost. The
following codes are defined:
Glass Expires 14 January 2001 [Page 8]
Internet Draft Registration Revocation for Mobile IP 14 July 2000
Value Meaning
----- -----------------------------------------------------------
0 Future registrations accepted
1 Future registrations with this care-of address denied
255 No future registrations accepted
Code value of 0 indicates only the current binding is lost, and
any new binding may be negotiated.
Code value of 1 indicates a mobile node may not use this care of
address. If this message is being sent to a colocated mobile node, it
SHOULD attempt to obtain another care-of address to be used in a
subsequent registration. If this message is being sent to a foreign
agent, it SHOULD set the "B" bit in it's unicast agent advertisement
to the mobile node indicating the mobile node SHOULD use a different
foreign agent when reregistering. If this message is being sent by a
foreign agent, it is indicating to the home agent that it will no
longer provide service for this mobile node. Such a foreign agent
SHOULD set the "B" bit in it's unicast agent advertisemetn to the
mobile node indicating the mobile node SHOULD use a different foreign
agent when reregistering.
A Code value of 255 means no future registrations will be approved
from this mobile node.
The code should be interpreted in conjunction with the lifetime.
For example, a code of 0 with a lifetime of 0 indicates the current
binding is revoked, and future registrations will be accepted
immediately. A code of 0 with a lifetime of 10 indicates the current
registration is revoked, and future registrations will be accepted
after 10 seconds have passed. For this reason, code 0 MUST NOT be
used with a lifetime of 255, and conversely code 255 MUST be used with
a lifetime of 255.
If a mobile node attempts to reregister before the revocation
lifetime has expired, the foreign agent MAY simply reply with error
65, "Administratively prohibited" saving it from tying up resources
while the registration would otherwise be pending approval by the home
agent.
It is expected that new codes will be added in the future
indicating what needs to be required in the new binding. For example,
if a mobile node is currently bound without a reverse tunnel defined,
but one is now required, the home agent may revok the current binding
with a new code indicating to the foreign agent that, if it supports
reverse tunneling, future registration requests which do not set the
"T" bit should be denied with error 75, "Reverse tunnel is mandatory
and 'T' bit not set" so the registration request does not have to come
to the home agent to be denied.
Glass Expires 14 January 2001 [Page 9]
Internet Draft Registration Revocation for Mobile IP 14 July 2000
4. Inter-Mobility Agent Communication
As the intent of a registration revocation message is not a
request, but essentially a notification, there are no new error codes.
If any Registration Revocation fails authentication, or replay
protection (as described in section 6 below), it MUST be silently
discarded.
Upon processing a registration revocation, a mobility agent MAY
repsond with its own registration revocation to indicate it has
received and processed the message.
5. Multiple Binding Support
RFC2002 [1] allows a mobile node to register multiple care-of
addresses with its home agent. Each one of these bindings is it's own
discrete tunnel, and hence can be treated as a separate case for
registration revocation. Consider the situation where a mobile node
has multiple care-of addresses registered with a single foreign agent
(either because the mobile node has multiple colocated care-of
addresses and the foreign agent has the 'R' bit set, or because the
foreign agent is multi-homed). Either agent can indicate the
revocation of all these bindings by setting the care-of address in the
registration revocation message to the zero address as described in
section 3.4 above.
If a foreign agent revoks a particular mobile node's binding(s)
with it, the home agent MAY or MAY NOT revok any of the mobile node's
other bindings (with other foreign agents). If a home agent is
revoking one of a mobile node's bindings, it MAY revoke none, or all
of the mobile node's other bindings as it sees fit. If a home agent
decides to revok a single binding for a mobile node, the foreign agent
MAY decide to revok other bindings for the same mobile node as it sees
fit.
6. Replay Protection
As Registration Revocation messages are designed to terminate
service for a mobile node, replay protection is crucial to prevent
denial of service attacks.
Replay protection is handled through a 32-bit identification field
in the registration revocation message. Whenever such a message is
received by a mobility agent, the authenticator MUST be checked, and
MUST be valid. If not the message MUST be silent discarded. After
the message has been authenticated, the ID field MUST NOT match that
in any other authenticated registration revocation message from the
same mobility agent (care-of address/home agent address), and for the
same mobile node home address. If the ID field is not unique, the
message MUST be silently discarded.
Glass Expires 14 January 2001 [Page 10]
Internet Draft Registration Revocation for Mobile IP 14 July 2000
Note: as it is possible for a mobile node to register at different
times with different home agents, and at different times with
different foreign agents, it is crucial that it not be required that
this ID feild be unique in messages from different agents as there is
no method for this information to be communicated between agents. For
example, if a mobile node has simultaneous bindingings with multiple
foreign agents, and these are being revoked, it is possible the
revocation message from one of the foreign agents may contain an ID
field that happens to match that of a previous registration
revocation. This MUST NOT result in the latter revocation message
being ignored.
7. Disparate Address, and Receiver Considerations
Since the registration revocation message comes from a source
address that is topologically routable from the interface receiving
the datagram, the agents, by definition, are topologically connected
(if this were not the case, the initial registration mechanism would
have failed). If either are connecting this topologically connected
region to one or more disparate address spaces no problems are
forseen. In order for the mobile node to have sucessfully registered
with its home agent, it MUST have provided the network to which it is
currently attached a routeable address of its home agent. Conversely,
the care of address being used by the mobile node must also be
topologically significant to the home agent in order for the
registration reply to have been received, and the tunnel initiated.
By definition, then, the home agent address and the care of address
must each be significant, and either address, when combined with the
mobile node's home address, must for a unique pair to the entity on
the other end of the tunnel.
Another way of understanding this is that the tunnel endpoint are
in some way connected, and hence are unique as far as the other end is
concerned. The address at the other end of the tunnel, in combination with
the address of the mobile node, must form a unique pair that can be
identified by the agent receiving the registration revocation message.
As an example, consider a mobile node who's home address lies in
disparate address space A behind it's home agent.
MN[a]-----[c]FA[b]-----((()))-----[b]HA[a]-----[a]CN
Address Some topologically Address
Space C conected network Space A
If we assume there must be a tunnel in existence at the time of
the registration revocation, namely between FA[b] and HA[b], then the
pair {FA[b],MN[a]} is guaranteed to be unique in the home agent
bindings, and the pair {HA[b],MN[a]} is guaranteed to be unique in the
foreign agent's visitor list.
Glass Expires 14 January 2001 [Page 11]
Internet Draft Registration Revocation for Mobile IP 14 July 2000
As a result of this, a home agent receiving a regstration
revocation message and FA-HA authenticator for MN[a] from (IP source
address) FA[b] is able to determine the unique mobile node address
being deregistered (if one is provided). Conversely a foreign agent
feceiving a registration revocation message and HA-FA authenticator
for MN[a] from HA[b] is able to determine the unique mobile node
address being deregistered (if one is provided).
8. Examples
T.B.D.
9. Security Considerations
[1] provides an existing security mechanism used by this
enhancement to [1]. All messages between entities on different
subnets MUST use the security mechanisms defined in [1], and are
therefore as secure as those in the core mobile IP protocol. As
registration revocation, when performed, terminates mobile IP services
being provided to the mobile node, it is crucial that all security and
replay protections mechanisms are used before a mobility agent accepts
the other agent has revoked a mobile node's binding, and cleans up the
resources it has reserved for this service. Messages which are sent
link-local MAY also be secured by methods outlined in [1].
10. Where to Direct Comments
Questions and comments about this draft should be directed at the
Mobile IP working group:
mobile-ip@standards.nortelnetworks.com
Questions and comments about this draft can also be directed to
the author:
Steven M. Glass
Internet Engineering
Sun Microsystems
1 Network Drive
Burlington, MA. 01801
Phone: 1.781.442.0504
Fax: 1.781.442.1706
E-mail: Steven.Glass@Sun.COM
Glass Expires 14 January 2001 [Page 12]
Internet Draft Registration Revocation for Mobile IP 14 July 2000
The working group may also be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation Motorola
6000 Connection Drive 1501 West Shure Drive
M/S M8-540
Irving, Texas 75039 Arlington Heights, IL 60004
USA USA
Phone: +1 972-894-6709 Phone: +1 847-632-3148
Fax : +1 972-894-5349
EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com
11. References
[1] C. Perkins, Editor. IPv4 Mobility Support. RFC 2002,
October 1996.
[2] G. Montenegro, Editor. Reverse Tunneling for Mobile IP.
RFC 2344, May 1998.
[3] D. Johnson, Mobility Support in IPv6, work in progress
Glass Expires 14 January 2001 [Page 13]
Internet Draft Registration Revocation for Mobile IP 14 July 2000
12.0 Full Copyright Statement
"Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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.
13.0 Working Group Chair's Address
The Working Group can be contacted via its current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation Motorola
M/S M8-540
6000 Connection Drive 1501 West Shure Drive
Irving, TX 75039 Arlington Heights, IL 60004
USA USA
Phone: +1 972-894-6709 Phone: +1 847-632-3148
EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com
Fax : +1 972-894-5349
Glass Expires 14 January 2001 [Page 14]