MIP4 Working Group H. Deng Internet-Draft Hitachi (China) Expires: December 25, 2006 H. Levkowetz Ericsson Research V. Devarapalli Azaire Networks S. Gundavelli Cisco Systems B. Haley Hewlett-Packard Company June 23, 2006 Generic Notification Message for Mobile IPv4 draft-deng-mip4-generic-notification-message-02.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 December 25, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies protocol enhancements that allow Mobile IPv4 Deng, et al. Expires December 25, 2006 [Page 1] Internet-Draft MIP4 Generic Notification Message June 2006 entities to send and receive explicit notification messages using a new Mobile IPv4 type designed for this purpose. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scenarios Requiring a Notification Message . . . . . . . . . . 5 3.1. Home Agent Initiates a Notification to the Mobile Node . . 5 3.1.1. Foreign Agent Care-of Address . . . . . . . . . . . . 5 3.1.2. Co-located Care-of Address . . . . . . . . . . . . . . 5 3.2. Foreign Agent Initiates a Notification to the Mobile Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Home Agent Initiates a Notification to the Foreign Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Generic Notification Message and Considerations . . . . . . . 7 4.1. Generic Notification Message . . . . . . . . . . . . . . . 7 4.2. Generic Notification Acknowledgment Message . . . . . . . 9 4.3. Mobile Node Consideration . . . . . . . . . . . . . . . . 11 4.3.1. Receiving Generic Notification Messages . . . . . . . 12 4.3.2. Sending Generic Notification Acknowledgement Message . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Foreign Agent Consideration . . . . . . . . . . . . . . . 13 4.4.1. Receiving Generic Notification Message . . . . . . . . 13 4.4.2. Sending Generic Notification Acknowledgement Message . . . . . . . . . . . . . . . . . . . . . . . 14 4.4.3. Sending Generic Notification Messages . . . . . . . . 15 4.5. Home Agent Consideration . . . . . . . . . . . . . . . . . 15 4.5.1. Sending Generic Notification Message . . . . . . . . . 15 4.5.2. Receiving Generic Notification Acknowledgement Messages . . . . . . . . . . . . . . . . . . . . . . . 16 4.5.3. Receiving Generic Notification Messages . . . . . . . 17 4.5.4. Sending Generic Notification Acknowledgement Messages . . . . . . . . . . . . . . . . . . . . . . . 17 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Revocation Extension . . . . . . . . . . . . . . . . . . . 18 5.2. Generic String Extension . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Deng, et al. Expires December 25, 2006 [Page 2] Internet-Draft MIP4 Generic Notification Message June 2006 1. Introduction In some situations, there is a need for Mobile IPv4 entities, such as the home agent, foreign agent and mobile node to send and receive asynchronous notification events during a mobility session. The base Mobile IP Specification [RFC3344] does not have a provision for this. This document defines a generic message and a notification model that can be used by Mobile IPv4 entities to send various notifications. However, this specification does not define any specific notification message or the actions that the receiving entity is required to perform on receiving that message. Specific extensions and the corresponding handler actions are outside the scope of this document. Deng, et al. Expires December 25, 2006 [Page 3] Internet-Draft MIP4 Generic Notification Message June 2006 2. Terminology It is assumed that the reader is familiar with the terminology used in [RFC3543], [RFC3344]. In addition, the following terms are defined: Notification Message A message from a mobility agent to a mobile node or other mobility agent to asynchronously notify it about an event that is relevant to the mobility service it is currently providing. 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 BCP 14, [RFC2119]. Deng, et al. Expires December 25, 2006 [Page 4] Internet-Draft MIP4 Generic Notification Message June 2006 3. Scenarios Requiring a Notification Message There are several scenarios where a mobility agent could initiate notification events. Some of these are described in the following sections. 3.1. Home Agent Initiates a Notification to the Mobile Node The home agent may wish to notify a mobile node about events such as load balancing, where the home agent wants to move some of the registered mobile nodes to other home agents; service termination due to end of prepaid time; or service interruption due to system maintenance. If the event requires some specific response from the mobile node, a new extension and specification needs to be defined for this. On the other hand, the notification could be intended for the user, for example, the message string extension [MIP4-STRING]. 3.1.1. Foreign Agent Care-of Address In this case, the home agent cannot directly notify the mobile node, but must send the notification via the foreign agent. +----+ notification +----+ notification +----+ | MN |<================| FA |<=============| HA | +----+ +----+ +----+ Figure 1: Home Agent notifies Mobile Node through Foreign Agent 3.1.2. Co-located Care-of Address In this case, the mobile node has registered with the home agent directly, so the notification message can go directly to the mobile node. The notification mechanism as specified here does not support the case of Co-located CoA mode with registration through a foreign agent (due to the 'R' bit being set in the foreign agent's advertisement messages). +----+ notification +----+ | MN |<===================================| HA | +----+ +----+ Figure 2: Home Agent directly notifies Mobile Node Deng, et al. Expires December 25, 2006 [Page 5] Internet-Draft MIP4 Generic Notification Message June 2006 3.2. Foreign Agent Initiates a Notification to the Mobile Node There are two cases where a foreign agent may send notification messages to a mobile node, one where it is relaying a message, the other where the notification is triggered by a message from another network entity, for example a AAA node. (notification messages between a AAA entity and the foreign agent could be based on RADIUS or Diameter, but this is out of scope for this document). If the notification is initiated by a foreign agent, the foreign agent may need to also notify the home agent about the event. +----+ notification +----+ notification +--------+ | MN |<================| FA |<=============| AAA/HA | +----+ +----+ +--------+ || notification +----+ ================>| HA | +----+ Figure 3: Foreign Agent notifies Mobile Node 3.3. Home Agent Initiates a Notification to the Foreign Agent The home agent may also need to send a notification to the foreign agent, but not to the mobile node, as illustrated below: +----+ notification +----+ | FA |<=============| HA | +----+ +----+ Figure 4: Home Agent notifies Foreign Agent Deng, et al. Expires December 25, 2006 [Page 6] Internet-Draft MIP4 Generic Notification Message June 2006 4. Generic Notification Message and Considerations This section describes in detail the generic notification message, generic notification acknowledgement message, and some considerations related to the handling of these messages in the mobile node, foreign agent and home agent. 4.1. Generic Notification Message A generic notification message is sent by a mobility agent to inform another mobility agent, or a mobile node, of MIP-related information. These messages must use the same IP and UDP headers as any previous Registration Request or Reply message to the same entity. The generic notification message is defined as follows: IP Fields: Source Address Sender's address. Destination Address Receiver's address. UDP Fields: Source Port variable. Destination Port Same as the last Registration Reply/Request message. 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 | Subtype |M|H|A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions... +-+-+-+-+-+-+-+-+-+-+-+-+- Deng, et al. Expires December 25, 2006 [Page 7] Internet-Draft MIP4 Generic Notification Message June 2006 Type (TBD) Subtype This field describes the particular type of notification which is carried in the notification message. M This bit indicates whether the receiver of the notification is a mobile node Set to "1" to indicate that if the message is intended for the mobile node. Set to "0" to indicate that if the message is not intended for the mobile node. H This bit indicates whether the sender of this message is the home agent or the foreign agent. Set to "1" to indicate that the sender is the home agent. Set to "0" to indicate that the sender is the foreign agent. A This bit indicates whether the notification message MUST be acknowledged by the recipient. Set to "1" to indicate that acknowledgement is required. Set to "0" to indicate that acknowledgement is optional. Reserved MUST be sent as 0, and ignored when received. Home Address The home IP address of the mobile node. Home Agent Address The IP address of the mobile node's home agent. Deng, et al. Expires December 25, 2006 [Page 8] Internet-Draft MIP4 Generic Notification Message June 2006 Care-of Address The mobile node's care-of address, either the co-located care-of address or the foreign agent care-of address. Identification A 64-bit number, constructed by the sender, used for matching Generic Notification with Generic Notification Acknowledgement, and for protecting against replay attacks of notification messages. See Sections 5.4 and 5.7 of [RFC3344]. Extensions The fixed portion of the Generic Notification Message is followed by one or more extensions which may be used with this message, and by one or more authentication extensions (as defined in Section 3.5 of [RFC3344]). See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for information on the relative order in which different extensions, when present, must be placed in a Generic Notification Message. 4.2. Generic Notification Acknowledgment Message A generic notification acknowledgement message is sent by mobility agents or mobile nodes to indicate the successful receipt of a generic notification message. IP Fields: Source Address Typically copied from the destination address of the Generic Notification to which the agent is replying. Destination Address Copied from the source address of the Generic Notification to which the agent is replying. UDP Fields: Source Port variable. Destination Port Copied from the source port of the corresponding Generic Notification. The UDP header is followed by the Mobile IP fields shown below: Deng, et al. Expires December 25, 2006 [Page 9] Internet-Draft MIP4 Generic Notification Message June 2006 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 | Subtype |M|H| Reserved | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions... +-+-+-+-+-+-+-+-+-+-+-+-+- Type (TBD) Subtype This field specifies the particular type of notification acknowledgement message. M This bit indicates whether the sender of this message is the mobile node or not. Set to "1" to indicate that the sender is the mobile node. Set to "0" to indicate that the sender is not the mobile node. H This bit indicates whether the receiver of this notification acknowledgement is the home agent or not. Set to "1" to indicate that the receiver is the home agent. Set to "0" to indicate that thee receiver is not the home agent. Reserved MUST be sent as 0, and ignored when received. Deng, et al. Expires December 25, 2006 [Page 10] Internet-Draft MIP4 Generic Notification Message June 2006 Status If the Generic Notification Message was received without error, this field is set to zero. However, if there is an error in reception, the field is nonzero with the following allowable codes defined in section 3.4 of [RFC3344]. Home Address The home IP address of the mobile node. Home Agent Address The IP address of the sender's home agent. Care-of Address The mobile node's care-of address, either the co-located care-of address or the foreign agent care-of address. Identification A 64-bit number used for matching Generic Notification with Generic Notification Acknowledgement, and for protecting against replay attacks of generic notification messages. The value is based on the Identification field from the Generic Notification message from the sender, and on the style of replay protection used in the security context between the receiver and sender (defined by the mobility security association between them, and SPI value in the authorization-enabling extension). See Sections 5.4 and 5.7 of [RFC3344]. Extensions The fixed portion of the generic notification acknowledgement message is followed by one or more of the Extensions listed in Section 3.5 of [RFC3344]. See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for information on the relative order in which different extensions, when present, MUST be placed in a Generic Notification message. 4.3. Mobile Node Consideration It is possible that the mobile node MAY receive a generic notification message from a foreign agent or home agent. Both in the case of FA-CoA and Co-located CoA, the mobile node MAY reply with a Generic Notification Acknowledgement message based on the "A" flag in the notification message. Deng, et al. Expires December 25, 2006 [Page 11] Internet-Draft MIP4 Generic Notification Message June 2006 4.3.1. Receiving Generic Notification Messages When the mobile node is using FA-CoA and receives a Notification message, if the "H" flag is set, it means that the notification message came from the home agnet. If the "H" flag is not set, the notification came from the foreign agent. In either case, the Mobile-Foreign Authentication extension MUST be used, and the mobile node MUST check the Authenticator value in the Extension. If no Mobile-Foreign Authentication Extension is found, or if more than one Mobile-Foreign Authentication Extension is found, or if the Authenticator is invalid, the mobile node MUST silently discard the Notification message. If this notification message came from a foreign agent and the mobile node accepts the foreign agent's generic notification message, it will process the notification extension according to the specific rules for that extension. After that, the mobile node MAY reply with a Generic Notification Acknowledgement message back to the foreign agent. If the "A" flag is set in the notification message, then the mobile node MUST send the acknowledgement. If this notification message came from the home agent, relayed by the foreign agent, or is a Co-located CoA, the Mobile-Home Authentication extension MUST be checked and the mobile node MUST check the Authenticator value in the Extension. If no Mobile-Home Authentication Extension is found, or if more than one Mobile-Home Authentication Extension is found, or if the Authenticator is invalid, the mobile node MUST silently discard the Notification message. If the mobile node accepts the home agent's generic notification message, it will process it according to the specific rules for that extension. After that, the mobile node MAY reply with a Generic Notification Acknowledgement message back to the home agent based on the "A" flag in the notification message. 4.3.2. Sending Generic Notification Acknowledgement Message Both in the case of a Co-located CoA and FA-CoA, the mobile node MAY reply with a Generic Notification Acknowledgement Message based on the "A" flag in the notification message as follows: In the case of FA-CoA, The source address is the mobile node's address, the destination address is the foreign agent address. If the notification message was initiated from the foreign agent to the mobile node ("M" flag is set to "1", "H" flag is set to "0"), the ordering of the extension is: any non-authentication Extensions used only by the foreign agent, followed by The Mobile-Foreign Deng, et al. Expires December 25, 2006 [Page 12] Internet-Draft MIP4 Generic Notification Message June 2006 Authentication extension defined in section 3.5.3 of [RFC3344]. ! If the notification message was initiated from the home agent to the mobile node ("M" flag is set to "1", "H" flag is set to "1"), the ordering of the extension is: any non-authentication Extensions used only by the foreign agent, followed by The Mobile-Foreign Authentication extension defined in section 3.5.3 of [RFC3344], followed by any non-authentication Extensions used only by the home agent, followed by the Mobile-Home Authentication extension defined in section 3.5.2 of [RFC3344] In the case of a FA-CoA, the source address is the mobile node's CoA address and the destination address is the home agent's address ("M" flag is set to "1", "H" flag is set to "1"), the ordering of the extension is: the Generic Notification extension, followed by any non-authentication extension expected to be used by home agent, followed by the Mobile-Home Authentication Extension defined in section 3.5.2. of [RFC3344]. 4.4. Foreign Agent Consideration The foreign agent cannot only relay generic notification message from the home agent and mobile node, but it can also initiate a generic notification message to the mobile node or home agent, but only when there is a binding for the mobile node. This means that the messaging is between the entities in the binding relation. 4.4.1. Receiving Generic Notification Message If the foreign agent receives a notification message, and the "M" flag is set to "1", it means that the home agent is asking the foreign agent to relay the message to the mobile node. Otherwise, it means that the target of the notification is the foreign agent. If the "M" flag is set to "0", the Foreign-Home Authentication extension MUST be checked, and the foreign agent MUST check the Authenticator value in the Extension. If no Foreign-Home Authentication Extension is found, or if more than one Foreign-Home Authentication Extension is found, or if the Authenticator is invalid, the foreign agent MUST silently discard the Notification message. If foreign agent accepts the home agent's generic notification message, it will process it based on the specific rules for that extension. The foreign agent MAY then reply with a Generic Notification Acknowledgement message back to the home agent based on the "A" flag in the notification message. If the "M" flag is set to "1", the Foreign-Home Authentication extension MUST be checked, and the foreign agent MUST check the Deng, et al. Expires December 25, 2006 [Page 13] Internet-Draft MIP4 Generic Notification Message June 2006 Authenticator value in the Extension. If no Foreign-Home Authentication Extension is found, or if more than one Foreign-Home Authentication Extension is found, or if the Authenticator is invalid, the foreign agent MUST silently discard the Notification message. If foreign agent accepts the home agent's generic notification message, it MUST relay the Generic Notification to the mobile node's home address as specified in the Home Address field of the Generic Notification. The foreign agent MUST NOT modify any of the fields beginning with the fixed portion of the Generic Notification message through and including the Mobile-Home Authentication Extension or other authentication extension supplied by the home agent as an authorization-enabling extension for the mobile node. Furthermore, the foreign agent MUST process and remove any Extensions following the Mobile-Home Authentication Extension and MAY append any of its own non-authentication Extensions of relevance to the mobile node, if applicable, and MUST append the Mobile-Foreign Authentication Extension, if the foreign agent shares a mobility security association with the Mobile Node. 4.4.2. Sending Generic Notification Acknowledgement Message The foreign agent may need to either relay a Generic Notification Acknowledgemnt message between the mobile node and the home agent or send one as a response to a notification messsage that was sent to it. In both cases, the Generic Notification Acknowledgement Message is defined as follows: The source address is the foreign agent address, the destination address is home agent address. if the foreign agent is only relaying this message to the home agent, the foreign agent it MUST NOT modify any of the fields beginning with the fixed portion of the Generic Notification Acknowledgement through and including the Mobile-Home Authentication Extension or other authentication extension supplied by the home agent as an authorization-enabling extension for the mobile node. Furthermore, the foreign agent MUST process and remove any Extensions following the Mobile-Home Authentication Extension and MAY append any of its own non-authentication Extensions of relevance to the home agent, if applicable. It MUST also append the Foreign-Home Authentication Extension, if the foreign agent shares a mobility security association with the home agent. If the notification message is from the home agent to the foreign agent then flag "M" is set to "0" and flag "H" is set to "1" and the ordering of the extension is: any non-authentication Extensions used only by the home agent, followed by The Foreign-Home Authentication extension defined in section 3.5.4 of [RFC3344]. Deng, et al. Expires December 25, 2006 [Page 14] Internet-Draft MIP4 Generic Notification Message June 2006 4.4.3. Sending Generic Notification Messages If the foreign agent is initiating a notification the mobile node using the generic notification message, it MAY also notify the home agent as well. In the message to the mobile node, the source address is the foreign agent address, the destination address is the mobile node's address, the "M" flag is set to "1" and the "H" flag is set to "0", and the ordering of the extension is: the notification extension, followed by any non-authentication Extensions used only by the mobile node, followed by The Mobile-Foreign Authentication extension defined in section 3.5.3 of [RFC3344]. Computing Authentication Extension Values is the same as section 3.5.1 of [RFC3344] except the payload is the notification other than registration. In the message to the home agent, the source address is the foreign agent's address, the destination address is the home agent's address, the "M" flag is set to "0" and the "H" flag is set to "0", The ordering of the extension is: notification extension, followed by any non-authentication Extensions used only by the home agent, followed by The Foreign-Home Authentication extension defined in section 3.5.4 of [RFC3344]. Computing Authentication Extension Values is the same as section 3.5.1 of [RFC3344] except the payload is the notification other than registration. 4.5. Home Agent Consideration Home agent MAY initiate a generic notification message to both the mobile node and foreign agent, and it also MAY receive a generic notification acknowledgement message from both the foreign agent and mobile node. The home agent also MAY receive a generic notification message from the foreign agent, but only when there is a binding for a mobile node. It can send a message to the mobile node or to the registered foreign agent in the path. This means that the messaging is between the entities in the binding relation. If the home agent receives a notification message from a foreign agent and there is no corresponding mobile node registration, the home agent should drop the notification message. 4.5.1. Sending Generic Notification Message In the case of FA CoA, the home agent may either send a notification message to notify the foreign agent, or have the foreign agent relay the notification message to the mobile node if the mobile node needs to the notified. if the message from the home agent to the foreign agent, the source Deng, et al. Expires December 25, 2006 [Page 15] Internet-Draft MIP4 Generic Notification Message June 2006 address is home agent's address, the destination address is the foreign agent's address if the foreign agent is working only as a relay agent, the "M" flag is set to "1" and the "H" flag is set to "1", and the ordering of the extension is: the notification extension, followed by any non- authentication extension expected to be used by mobile node, followed by Mobile-Home Authentication Extension defined in section 3.5.2. of [RFC3344], followed by any non-authentication Extensions used only by the foreign agent, followed by The Foreign-Home Authentication extension defined in section 3.5.4 of [RFC3344]. Computing Authentication Extension Values is the same as section 3.5.1 of [RFC3344]. if the foreign agent is the target of this notification message, then the "M" flag is set to "0" and the "H" flag is set to "1", The ordering of the extension is: the notification extension, followed by any non-authentication Extensions used only by the foreign agent, followed by The Foreign-Home Authentication extension defined in section 3.5.4 of [RFC3344]. Computing Authentication Extension Values is the same as section 3.5.1 of [RFC3344]. 4.5.2. Receiving Generic Notification Acknowledgement Messages In the case of FA-CoA, if the home agent receives this message, and the "M" flag is set to "1", it means that the notification acknowledgement message came from mobile node, otherwise it came from the foreign agent. The Foreign-Home Authentication extension MUST be checked, and the home agent MUST check the Authenticator value in the Extension. If no Foreign-Home Authentication Extension is found, or if more than one Foreign-Home Authentication Extension is found, or if the Authenticator is invalid, the home agent MUST silently discard the Notification Acknowledgement message. if the "M" flag is set to "0", and the home agent accepted this message, and the Status field indicates that the notification was accepted by the foreign agent, the home agent MAY also process it based on the notification event. if the "M" flag is set to "0", and the home agent accepted this message, the Mobile-Home Authentication extension MUST be checked, and the home agent MUST check the Authenticator value in the Extension. If no Mobile-Home Authentication Extension is found, or if more than one Mobile-Home Authentication Extension is found, or if the Authenticator is invalid, the home agent MUST silently discard the Notification Acknowledgement message. if the home agent accepted this message, and the Status field indicates that the notification was accepted by the mobile node, home agent MAY also process it based Deng, et al. Expires December 25, 2006 [Page 16] Internet-Draft MIP4 Generic Notification Message June 2006 on the notification event. In the case of Co-located CoA, if the home agent received this message, the Mobile-Home Authentication extension MUST be checked, and the home agent MUST check the Authenticator value in the Extension. If no Mobile-Home Authentication Extension is found, or if more than one Mobile-Home Authentication Extension is found, or if the Authenticator is invalid, the home agent MUST silently discard the Notification Acknowledgement message. For all Generic Notification Acknowledgement messages containing a Status Code indicating status from the mobile node, If the Status field indicates that the notification was accepted by the mobile node, home agent MAY process it based on the notification event. 4.5.3. Receiving Generic Notification Messages the home agent MAY receive generic notification messages which are sent from the foreign agent. When the home agent receives this message, and the Foreign-Home Authentication extension MUST be checked, the home agent MUST check the Authenticator value in the Extension. If no Foreign-Home Authentication Extension is found, or if more than one Foreign-Home Authentication Extension is found, or if the Authenticator is invalid, the home agent MUST silently discard the Notification message. If home agent accepts the foreign agent's generic notification message, it will process it based on the notification extension. Furthermore, the home agent MAY reply with a Generic Notification Acknowledgement message back to the foreign agent based on the "A" flag in the notification message. 4.5.4. Sending Generic Notification Acknowledgement Messages If the generic notification message came from the foreign agent only, the home agent MAY reply with a generic notification acknowledgement message to the foreign agent based on the "A" flag in the notification message. if the "A" flag is set in the notification message, then the home agent must send a Notification Acknowledgement message. The message is as follows: The source address is home agent's address, the destination address is the foreign agent's address, the "M" flag is set to "0" and the "H" flag is set to "0". The ordering of the extension is: any non-authentication Extensions used only by the foreign agent, followed by The Foreign-Home Authentication extension defined in section 3.5.4 of [RFC3344]. Deng, et al. Expires December 25, 2006 [Page 17] Internet-Draft MIP4 Generic Notification Message June 2006 5. Usage Example There are several applications that could use this generic notification message. for example, during handover between CDMA 2000 1x EV-DO and Wireless LAN, the PPP resource of CDMA side have to be removed on the foreign agent (PDSN) to avoid over-charging subscribers. Other applications such as registration revocation, home agent switch over, NEMO prefix changes, and service or billing related events. Here we give a example of using revocation extension and describe some possible event which could use the generic string extension based on this notification mechanism also. There is also the possibility that this notification message could carry many extensions at once. A new VSE extension could be defined to support this notification message. 5.1. Revocation Extension If an agent would like to notify another agent about registration revocation [RFC3543], it could easily be carried by a generic notification message and generic notification acknowledgement. One would just specify the exact number of "Subtype" in this two messages. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length |I| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 5.2. Generic String Extension In some case, the home agent or foreign agent needs to notify mobile node about service termination due to the end of prepaid time, or service interruption due to system maintenance. This information could be defined based on a string which is recognized by mobile node easily. An example would be "Maintenance Stopping", "Prepaid Expire". These string MUST be strictly defined so they could be easily understood by all of the network entities. "Subtype" number will be decided by working group. Deng, et al. Expires December 25, 2006 [Page 18] Internet-Draft MIP4 Generic Notification Message June 2006 6. Security Considerations Mobile IP Generic Notification and Generic Notification Acknowledgement are authenticated, and the authentication verified by the recipient. Deng, et al. Expires December 25, 2006 [Page 19] Internet-Draft MIP4 Generic Notification Message June 2006 7. IANA Considerations This document describes two new messages, the Generic Notification message, section 4.1 and the Generic Notification Acknowledgement message, section 4.2. These two messages should be allocated from the same address space used by the Registration Request and Registration Reply messages in [RFC3344] Deng, et al. Expires December 25, 2006 [Page 20] Internet-Draft MIP4 Generic Notification Message June 2006 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003. 8.2. Informative References [MIP4-STRING] Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message String Extension", Jan 2006, . Deng, et al. Expires December 25, 2006 [Page 21] Internet-Draft MIP4 Generic Notification Message June 2006 Authors' Addresses Hui Deng Hitachi (China) Beijing Fortune Bldg. 1701 5 Dong San Huan Bei-Lu Chao Yang District Beijing 100004 China Email: hdeng@hitachi.cn Henrik Levkowetz Ericsson Research Torshamsgatan 23 S-164 80, Stockholm SWEDEN Email: henrik@levkowetz.com Vijay Devarapalli Azaire Networks 4800 Great America Pkwy Santa Clara, CA 95054 USA Email: vijay.devarapalli@azairenet.com Sri Gundavelli Cisco Systems 170 W.Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Brian Haley Hewlett-Packard Company 110 Spitbrook Road Nashua, NH 03062 USA Email: brian.haley@hp.com Deng, et al. Expires December 25, 2006 [Page 22] Internet-Draft MIP4 Generic Notification Message June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Deng, et al. Expires December 25, 2006 [Page 23]