MIP6 WG A. Muhanna Internet-Draft M. Khalil Intended status: Standards Track Nortel Networks Expires: November 25, 2007 S. Gundavelli Cisco K. Chowdhury Starent Networks P. Yegani Cisco May 24, 2007 Binding Revocation for IPv6 Mobility draft-muhanna-mip6-binding-revocation-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 25, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The service binding revocation semantics are missing in Mobile IPv6 Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document Muhanna, et al. Expires November 25, 2007 [Page 1] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 defines the semantics of the revocation of a mobile node registration binding, which could have been established using a Client Mobile IPv6 or a Proxy Mobile IPv6 signaling. The proposed revocation mechanism uses generic message properties which is applicable to Mobile IPv6 and Proxy Mobile IPv6 and can be used by any two mobility entities. As an example, this mechanism allows local mobility agent, involved in providing IP mobility services to a mobile node, to notify the mobility access gateway of the termination of the mobile node registration. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Message Formats . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Binding Revocation Indication Message . . . . . . . . 4 3.1.2. Binding Revocation Acknowledgement Message . . . . . . 5 3.2. Revocation Signaling and Use Cases . . . . . . . . . . . . 7 3.2.1. Use Case No. 1: HA to MN . . . . . . . . . . . . . . . 7 3.2.2. Use Case No. 2: LMA to MAG . . . . . . . . . . . . . . 8 3.2.3. Use Case No. 3: MAG to LMA . . . . . . . . . . . . . . 9 3.3. Bulk Binding Termination . . . . . . . . . . . . . . . . . 11 3.4. MAG Operational Summary . . . . . . . . . . . . . . . . . 12 3.5. LMA Operational Summary . . . . . . . . . . . . . . . . . 13 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Binding Revocation Signaling in Global Mobility . . . . . . . 14 6. Binding Revocation Signaling in Proxy MIPv6 Domain . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Muhanna, et al. Expires November 25, 2007 [Page 2] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 1. Introduction In the case of Mobile IPv6 and for administrative reasons, sometimes it becomes necessary to inform the mobile node that its registration has been revoked and the MN is no longer able to receive IP mobility service. The binding revocation semantics are missing from the Mobile IPv6 specification [RFC-3775] and Proxy MIPv6 base protocol [PMIP-SPEC]. This document defines the semantics of the revocation mechanism of a mobile node registration binding, which could have been established using a Client Mobile IPv6 or a Proxy Mobile IPv6 signaling. The proposed revocation mechanism uses generic message properties which is applicable to Mobile IPv6 and Proxy Mobile IPv6 and can be used by any two IP mobility entities. As an example, this mechanism allows local mobility agent, involved in providing IP mobility services to a mobile node, to notify the mobility access gateway of the termination of the mobile node registration. 2. Conventions used in this document The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. All the general mobility related terminology and abbreviations are to be interpreted as defined in Mobile IPv6 specification [RFC-3775] and Proxy Mobile IPv6 specification [PMIP6-SPEC]. 3. Protocol Overview The revocation procedure can be intiated by the HA in situations such as when the network decides to terminate the service of the MN. If the HA decided to terminate the service of the MN, the HA MAY send a Binding Revocation Indication (BRI) message to the MN. In the case of Proxy Mobile IPv6 (PMIPv6), the LMA sends the BRI message to the MAG to indicate the revocation of a mobile node registration. When the MAG receives the BRI message it looks up the MN binding, deletes the MN binding, and cleanup all the reserved resources allocated for this MN and in the case that the LMA requested an acknowledgement, the MAG sends a Binding Revocation Acknowledgement (BRA) message to the LMA. Muhanna, et al. Expires November 25, 2007 [Page 3] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 3.1. Message Formats This section defines two new mobility header messages. 3.1.1. Binding Revocation Indication Message The Binding Revocation Indication (BRI) message is used by the LMA or the MAG to notify the peer mobility agent that the mobility service of the specified MN session or sessions have been revoked in order for the peer mobility node to take the proper action and cleanup the associated resources. This message can also be used by the HA to indicate to the MN that its mobility binding has been revoked. The BRI message uses the MH Type value (TBD, to be assigned by IANA). When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # |P|A|G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Binding Revocation Indication Message Muhanna, et al. Expires November 25, 2007 [Page 4] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 Sequence # A two byte sequence number. The mobility agent, LMA/HA or MAG sets this sequence number to the next available number after the last used sequence number. The sending mobility node use this sequence number to match the BRA to the outstanding BRI message. Proxy Binding (P) The Proxy Binding (P) bit is set by the sending mobility node to indicate that the revoked binding is a proxy MIPv6 binding entry. Acknowledge (A) The Acknowledge (A) bit is set by the sending mobility node, LMA, HA or MAG to request the peer mobility node to acknowledge recieiving the BRI message via BRA message. Global Per-Peer Bindings (G) The Global Per-Peer Bindings (G) bit is set by the sending mobility node, LMA/HA or MAG, to request the receiving peer mobility node to revoke all sessions which served by both peers. Reserved This field is reserved for future use. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Mobility Options A mobility option(s) that is used to identify a specific session or sessions that their registration(s) are being revoked. 3.1.2. Binding Revocation Acknowledgement Message The Binding Revocation Acknowledge (BRA) message is sent from the MN, MAG, or the LMA/HA in response to a mobility node Binding Revocation Indication message. The BRA message uses the MH Type value (TBD, to be assigned by IANA). When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: Muhanna, et al. Expires November 25, 2007 [Page 5] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Status |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Binding Revocation Acknowledgement Message Sequence # A two byte sequence number. When the MN or a mobility agent, MAG or LMA/HA sends a BRA message, it must copy the sequence number from the corresponding sequence number field of the BRI message. Status A one byte which indicates the result of processing the corresponding BRI message by the reciving mobility entity. 0 success. 1 failure unspecified. 2 MN BCE does not exist. Proxy Binding (P) The Proxy Binding (P) bit is set if the same P bit is set in the corresponding recievd BRI message by the sending mobility entity to indicate that the revoked binding is a proxy binding entry. Reserved This field is reserved for future use. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Mobility Options The mobility option(s) usually match those recived in the corresponding BRI message. Muhanna, et al. Expires November 25, 2007 [Page 6] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 3.2. Revocation Signaling and Use Cases This section defines how the revocation signaling can be used by mobility entities for the purpose of revoking a binding registration, discontinue of the IP mobility services, and state cleanup. The subsections below define the different applicable use cases. The home agent sends a binding revocation indication message to a mobile node to inform the MN that its MIPv6 registeration has been revoked and no longer authorized to receive IP mobility services. Whenever HA sends a BRI message, HA MAY set the A bit to indicate that the MN SHOULD respond with a BRA message. The following subsections summarize a list of use cases that binding revocation mechanism is necessary for. 3.2.1. Use Case No. 1: HA to MN In this case, HA sends a BRI message to indicate to the MN that its current mobile IPv6 binding has been revoked a it no longer can receive IP mobility service. The BRI includes the mobile node home address in the home address option and optionally the MN-ID, i.e. NAI. If the MN process the BRI message, it SHOULD send a BRA messsage to the HA if the A bit is set. Figure-3 illustrates the message sequencing when HA revokes a MN binding registration. MN HA | | | BRI[seq.#x, P,A bits, HoA option] | |<------------------------------------| | | | | | BRA[seq.#x, P bits, HoA option] | |------------------------------------>| | | | | Figure 3: HA Revokes a Mobile Node Registration Muhanna, et al. Expires November 25, 2007 [Page 7] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 3.2.2. Use Case No. 2: LMA to MAG In this case, LMA MAY send a BRI message to the MAG, hosting a specific MN mobile IPv6 session, to indicate that the mobile IPv6 binding of a specific MN session, which is registered and anchored at the LMA, has been revoked and MAG can clean up the associated resources. If the MAG processes the BRI message, the MAG MUST send a BRA message in response to the LMA if the A bit in the BRI message is set. In this case, the MAG SHOULD send a unicast RA message to the MN local link IP address with the home network prefix lifetime is set to zero. As an example, Figure-4, illustrates the message sequence for revoking a MN binding at the source MAG during the MN inter-MAG handoff. During the inter-MAG handoff, the MN moves from the source MAG to the target MAG. The target MAG sends a PBU with the new care- of-address to the LMA to update the mobile node location. Since the MN binding at the LMA points to the source MAG and upon receiving the PBU from the target MAG, LMA updates the MN BCE and send a PBA to the target MAG. LMA MAY send a BRI message to the source MAG to clean up the resources reserved for the specified MN. If the LMA sets the A bit in the BRI and the MAG processes the BRI message, the MAG MUST send a BRA message to indicate the success or failure of the MN revocation. The process identified above can be used by the LMA in scenarios other than the inter-MAG handoff to indicate to the peer MAG that a specific mobile IPv6 session or sessions bindings have been revoked. Muhanna, et al. Expires November 25, 2007 [Page 8] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 sMAG tMAG LMA | | | | | PBU | | |--------------------------->| | | PBU triggers | | BRI Msg to sMAG | | | | | PBA | | |<---------------------------| | | | | | | | BRI [seq.#y, P,A bits, HoA option] | |<-----------------------------------------| | | | | | | | | | | | | | BRA [seq.#y, P bit, HoA option | |----------------------------------------->| | | | | | | Figure 4: LMA Revokes a MN Registration During Inter-MAG Handoff 3.2.3. Use Case No. 3: MAG to LMA In the case when the MAG recieves a direct or indirect indication or the MAG finds that the MN has moved a way and no longer attached to the it, the MAG MAY send a BRI message to indicate to the LMA that the MN session binding has been cleaned up at the MAG and the LMA needs to clean up the allocated and reserved resources. If the LMA processes the BRI message and the A bit is set, the LMA MUST send a BRA message in response to the MAG. Since there is no guranteed indication to the LMA that the MAG has sent the BRI message due to a MN move during an inter-MAG handoff, the LMA SHOULD start a T_Handoff_Progress_timer to make sure that the MN session binding survives an inter-MAG handoff. Figure-5 and Figure-6 illustrate the message flow for two scenarios. Muhanna, et al. Expires November 25, 2007 [Page 9] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 sMAG tMAG LMA | | | | | | | | | | BRI [seq.#y, P,A bits, HoA option] | |----------------------------------------->| | | Start | | T_handoff_Progress | | timer | | | | BRA [seq.#y, P bit, HoA option] | |<-----------------------------------------| | | | | | | | | PBU | | |--------------------------->| | | Cancel | | T_handoff_progress | | timer | | | | | PBA | | |<---------------------------| | | | | | | Figure 5: sMAG Revokes a MN Registration During Inter-MAG Handoff Muhanna, et al. Expires November 25, 2007 [Page 10] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 MAG LMA | | Indication to MAG | MN Exited Network | | | | BRI [seq.#y, P,A bits, HoA option] | |----------------------------------------->| | Start | T_handoff_Progress | timer | | | BRA [seq.#y, P bit, HoA option] | |<-----------------------------------------| | | | T_handoff_progress | timer Expires | | | LMA Cleans Up | MN Binding | | | | Figure 6: MAG Informs LMA of Cleaning the MN Binding and Resources 3.3. Bulk Binding Termination HA/LMA MAY send a BRI message to indicate that all sessions which are hosted by the MAG and registered with the HA/LMA MUST be revoked by setting the G bit and including the HA IP address in the home address option. Similarly, the MAG MAY send a BRI message to request that all sessions which are registered at the LMA and attched to the MAG MUST be revoked by setting the G bit and including the MAG IP address in the care-of-address option. The above two cases are usefull in the case of scheduled maintenance at the LMA or the MAG in order to ensure that all resources at the other mobility entity is properly released and cleaned up. In the case of MAG scheduled maintenance, the MAG MAY broadcast RA messages with router lifetime of zero. Muhanna, et al. Expires November 25, 2007 [Page 11] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 3.4. MAG Operational Summary o When MAG revokes a specific session of a mobile node, MAG MAY send a BRI message with the home address option or the per-MN home prefix option included. MAG MUST set the P and A bits in the BRI message to indicate that the session is a proxy MIPv6 session and ensure that the LMA sends a BRA message to acknowledge processing the BRI message. o In some circumistances, MAG has a scheduled maintenance, the MAG MAY indicate to the LMA that all PMIPv6 sessions which are hosted at the MAG and registered with the LMA must be revoked by sending a BRI message with the G bit is set and the MAG IP Address is included in the care-of-address option. o In the case that the MAG can identify several mobile nodes sessions as per a specific subnet prefix, MAG MAY send a BRI message with the specific prefix included in the home prefix option after setting the P and A bits to revoke the binding registrations of these mobile nodes. o When the mobility access gateway receives a BRI message from the LMA on the secure tunnel with the LMA, MAG locates the mobile node or nodes that are being revoked as per the recieved BRI by examining the mobility options included in the received BRI message. If the home address option is included, MAG MUST revoke that MN specific session and sends a BRA message to the LMA after copying the sequence number from the BRI into the BRA sequence number field. If the Home Netork Prefix option is included, the MAG revokes all mobile nodes BCE which use the specified prefix. However, if the G bit is set and the HA IP address is included in the home address option, the MAG must revoke all MNs which are hosted by the MAG and registered with the peer LMA. After processing the received BRI, the MAG MUST always acknowledge receiving the BRI message by sending a BRA message to the LMA which sent the BRI message. o When the MAG recieves a BRI message from the LMA and the MAG fails to find the associated BCE, the MAG SHOULD send BRA message with the status field is set "MN BCE does not exist" to indicate revocation has failed . The MAG MAY choose not to respond to the BRI message, however, the LMA will retransmit the BRI message. o The MAG MUST use the security association that has been used during the Proxy MIPv6 sessions establishment with the peer LMA to secure the BRI and BRA messages transmission with the LMA. Muhanna, et al. Expires November 25, 2007 [Page 12] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 3.5. LMA Operational Summary o When LMA revokes a specific session of a mobile node, LMA MAY send a BRI message to the MAG with the MN specific home address included in the home address option or the per-MN home prefix included in the home network prefix option. LMA MUST set the P and A bits in the BRI message to indicate that the session is a proxy MIPv6 session and that the MAG SHOULD send a BRA message to acknowledge processing the BRI message. o In the case of revoking all sessions associated with a mobile node, the LMA sends a BRI message to the MAG which includes the MN ID , e.g. NAI, in the MN ID option. o In some circumistances, LMA has a scheduled maintenance, the LMA indicates to the MAG that all PMIPv6 sessions which are registered at the LMA and hosted at the MAG must be revoked by sending a BRI message with the G bit set and the HA IP Address is included in the home address option. o In the case when the LMA can identify several mobile nodes sessions per a single subnet prefix, LMA sends a BRI message with the specific prefix in the home network prefix option after setting the P and A bits to revoke the binding registration of all these mobile nodes. o When the local mobility anchor receives a BRI message from a MAG on the secure tunnel, LMA defined the mobile node or nodes that are revoked by this BRI by examining the proper mobility options included in the BRI message. If the home address option is included, LMA revoke that specific session of the user and sends BRA message after copying the sequence number from the BRI into the BRA sequence number field. If the Home prefix option is included, the LMA revoke all mobile nodes BCE which use the specified prefix. However, if the G bit is set and the MAG IP address is included in the care-of-address option, LMA must revoke all MNs which is hosted by the MAG and registered with the LMA. The LMA MUST always acknowledge receiving a BRI message by sending a BRA message to the peer which sent the BRI message. o I the case of mobile node handover from the source MAG to the target MAG, LMA MAY recieve a PBU from the target MAG to update the MN BCE with the new CoA. After LMA update the MN BCE, LMA SHOULD send a BRI with the P and A bits set and include either the MN home address in the home address option or the per-MN home prefix in the home prefix option to indicate to the source MAG to clean up the MN associated resources. Muhanna, et al. Expires November 25, 2007 [Page 13] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 o When LMA recieves a BRI message from the MAG and the LMA fails to find the associated BCE, LMA SHOULD send BRA message with status is set to revocation failed MN does not exist if the A bit is set in the BRI. The LMA MAY choose NOT to respond to the BRI message, however, the MAG MAY retransmit the BRI message. o The local mobility anchor MUST use the same security association that has been used during the Proxy MIPv6 sessions with the specified MAG to secure the BRI and BRA messages transmission with the MAG. 4. Security Model The protocol described here uses the same per node security association between the MN and the HA or the MAG and the LMA that has been used to exchange the corresponding Client MIPv6 or Proxy MIPv6 BU and BA when the sesiion was established. In the case when the LMA receive a BRI which indicate a bulk termination, the LMA MUST verify that the MAG sending the revocation message is authorized for this kind iof revocation. 5. Binding Revocation Signaling in Global Mobility Binding revocation mechanism is applicable to Client Mobile IPv6 session when the Home Agent needs to inform the MN that its binding registration has been revoked for an administrative reasons or probably due to the Mobile IPv6 user running out of money. This mechanism will enable the home domain to dynamically allow the Mobile IPv6 user to act upon the message in order to not have an unexpected intterrupted mobile IPv6 services. One of the important scenarios that is applicable to RFC3775 content is when the MN returns home. According to RFC3775, the MN is recommended to send a BU message with lifetime of zero, however, RFC3775 recommended but did not mandate this behaviour on the MN. In this case, if the HA detects that the MN has returned home and did not send a deregistration BU with a lifetime of zero, the HA MAY send a BRI message to the MN using the same security association that the MN and HA negotiated and used during the exchange of the initial BU and BA messages. It is recommended that if the MN recieves and process a BRI message Muhanna, et al. Expires November 25, 2007 [Page 14] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 that the MN SHOULD send a BRA message if the HA had the A bit set in the BRI. 6. Binding Revocation Signaling in Proxy MIPv6 Domain Since the Mobile node does not participate in the mobility mechaniism in the case of PMIPv6, there many scenarios where Binding Revocation mechanism is needed to clean resources and make sure that the mobility entities, e.g. MAG and LMA, always synchronized with the status of the exsiting proxy mobile IPv6 sessions. The binding revocation mechanism is generic enough that can address all aplicable scenarios and deployment options. For example, this revocation mechanism is applicable and can be used for IPv6 and IPv4 transports and when the MN uses IPv4 or IPv6 address. When the MAG or the LMA receives and successfully processes a BRI with the A bit is set, the receiving mobility agent MUST send a BRA message to the sending mobility agent to acknowledge processing the BRI message. 7. IANA Considerations This document defines two new Mobility Header type messages, BRI and BRA, as described in Section 3.1. The new Mobility Header type values needs to be assigned from the same numbering space as allocated for the other Mobility Header types. 8. Security Considerations The protocol described here uses the same per node Isecurity association between the MN and the HA or the MAG and the LMA that has been used to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the session was established. However, in the case when the MAG sends a BRI message with the G bit is set, the LMA MUST verify that the MAG is authorized to indicate such event. Muhanna, et al. Expires November 25, 2007 [Page 15] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 9. Acknowledgements The authors would like to thank their colleuges who would volunteer to review this document and provide their feedback. Thanks in adavnce. 10. References 10.1. Normative References [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2003. [PMIP6-SPEC] Gundavelli, S., et al., "Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-00 (work in progress), April 2007. [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 4303, December 2005. [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. 10.2. Informative References [RFC-2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC-3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC-3344] S. Glass and M. Chandra, "Registration Revocation in Mobile IPv4", RFC3543, August 2003. [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", RFC 4301, December 2005. Muhanna, et al. Expires November 25, 2007 [Page 16] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 Authors' Addresses Ahmad Muhanna Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: amuhanna@nortel.com Mohamed Khalil Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: mkhalil@nortel.com Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 USA Email: kchowdhury@starentnetworks.com Parviz Yegani Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: pyegani@cisco.com Muhanna, et al. Expires November 25, 2007 [Page 17] Internet-Draft Binding Revocation for IPv6 Mobility May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Muhanna, et al. Expires November 25, 2007 [Page 18]