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]