MIP4 Working Group H. Deng Internet-Draft Hitachi (China) Expires: April 20, 2006 H. Levkowetz Ericsson Research V. Devarapalli Nokia Research Center S. Gundavelli Cisco Systems B. Haley Hewlett-Packard Company October 17, 2005 Generic Notification Message for Mobile IPv4 draft-deng-mip4-generic-notification-message-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 April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies protocol enhancements that allow Mobile IPv4 Deng, et al. Expires April 20, 2006 [Page 1] Internet-Draft MIP4 Generic Notification Message October 2005 entities to send and receive explicit notfication messages using a generic message header defined in this specification. 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. FA CoA Case . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Co-located CoA Case . . . . . . . . . . . . . . . . . 5 3.2. Foreign Agent Initiates a Notification to the Mobile Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Home Agent Initiates a Notification to the Foreign Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Generic Nofitication Message and Considerations . . . . . . . 7 4.1. Generic Notifcation Message . . . . . . . . . . . . . . . 7 4.2. Generic Notifcation Acknowledgment Message . . . . . . . . 9 4.3. Mobile Node Consideration . . . . . . . . . . . . . . . . 11 4.3.1. Receiving Generic Notification Messages . . . . . . . 11 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 Message . . . . . . . . . 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 Message . . . . . . . . . . . . . . . . . . . . . . . 17 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1. Revocation Extension . . . . . . . . . . . . . . . . . . . 19 5.2. Generic String Extension . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.1. New Message Types . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Deng, et al. Expires April 20, 2006 [Page 2] Internet-Draft MIP4 Generic Notification Message October 2005 1. Introduction There is a need for the Mobile IPv4 entities, such as the home agent, foreign agent and the 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 describes a generic signaling mechanism by the home agent, foreign agent and mobile node to notify each other securely. This document defines a generic header and a notification model that can be used by the Mobile IPv4 entities to carry various signalling messages. However, this specification does not define any specific notification message or the actions that the receiving entity is required to perform on receiving that messages. The specific messages and the corresponding handler actionsare outside the scope of this document. Deng, et al. Expires April 20, 2006 [Page 3] Internet-Draft MIP4 Generic Notification Message October 2005 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 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 April 20, 2006 [Page 4] Internet-Draft MIP4 Generic Notification Message October 2005 3. Scenarios Requiring a Notification Message There are several possibilities that different mobility agent could initiate notification events with section 3.1, 3.2 and 3.3. 3.1. Home Agent Initiates a Notification to the Mobile Node The home agent MAY 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. The actual even information could be transfered by generic string extension. 3.1.1. FA CoA Case The home agent can not directly notify mobile node, this notification has to be sent via the foreign agent. +----+ notification +----+ notification +----+ | MN |<================| FA |<=============| HA | +----+ +----+ +----+ Figure 1: Home Agent Notify Mobile Node through Foreign Agent 3.1.2. Co-located CoA Case Since mobile node register to home agent directly, this notification message can go to the mobile node directly. Here Co-located CoA mode with R bit will not be considered. +----+ notification +----+ | MN |<===================================| HA | +----+ +----+ Figure 2: Home Agent Notify Directly Mobile Node 3.2. Foreign Agent Initiates a Notification to the Mobile Node There are two cases where foreign agent may send notifcation messages to mobile node, one where it is relaying a message, the other is triggered by a message from another network entity, for example, AAA. Notification messages between a foreign agent and a AAA entity could be based on RADIUS or Diameter. It is out of scope for this document. If the trigger is initiated by a foreign agent, the foreign agent MAY need to notify the home agent also about this Deng, et al. Expires April 20, 2006 [Page 5] Internet-Draft MIP4 Generic Notification Message October 2005 event. +----+ notification +----+ notification +--------+ | MN |<================| FA |<=============| AAA/HA | +----+ +----+ +--------+ || notification +----+ ================>| HA | +----+ Figure 3: Foreign Agent Notify Mobile Node 3.3. Home Agent Initiates a Notification to the Foreign Agent There are cases where the home agent may need to send a notification to the foreign agent but not to the mobile node. +----+ notification +----+ | FA |<=============| HA | +----+ +----+ Figure 4: Home Agent Notify Foreign Agent Deng, et al. Expires April 20, 2006 [Page 6] Internet-Draft MIP4 Generic Notification Message October 2005 4. Generic Nofitication Message and Considerations This section describe in detail the generic notification message, generic notification acknowledgement message, and some considerations 4.1. Generic Notifcation Message A generic notification message is sent by a mobility agent to inform another mobility agent, or a mobile node of an event. these messages must use the same IP and UDP headers as any previous RRP to the same entity. The generic 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... +-+-+-+-+-+-+-+-+-+-+-+-+- Type (TBD) Deng, et al. Expires April 20, 2006 [Page 7] Internet-Draft MIP4 Generic Notification Message October 2005 Subtype This field describes the particular type notiifcation which is carried in the Notification field. M This bit identifies the receiver of this notification will go to mobile node or not. Set to "1" to request this message going to mobile node. Set to "0" to request this message not going to mobile node. H This bit identifies the sender of this message is home agent or foreign agent. Set to "1" to indicate the sender is home agent. Set to "0" to indicate the sender is foreign agent. A This bit identifies whether the notification message MUST be acknowledged by the receipent. Set to "1" to indicate MUST be acknowledged. Set to "0" to indicate MUST not be acknowledged. Reserved MUST be sent as 0, 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. Care-of Address The IP address for the end of the tunnel. Deng, et al. Expires April 20, 2006 [Page 8] Internet-Draft MIP4 Generic Notification Message October 2005 Identification A 64-bit number, constructed by the sender, used for matching Generic Notfication 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 is followed by a notification extension or various extension such as string generic string extension, and by one or more of the Extensions listed in Section 3.5 of 2. 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 Notifcation Acknowledgment Message A generic notification acknowledgment 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 April 20, 2006 [Page 9] Internet-Draft MIP4 Generic Notification Message October 2005 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 | Status |M|H| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent / Foreign Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions... +-+-+-+-+-+-+-+-+-+-+-+-+- Type (TBD) Subtype This field describes the particular type notiifcation which is carried in the Notification field. 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]. M This bit identifies the receiver of this notification acknowledgement will go to mobile node or not. Set to "1" to indicate the sender is mobile node. Set to "0" to indicate the sender is not mobile node. H This bit identifies the sender of this message is home agent or foreign agent. Set to "1" to request this message going to home agent. Deng, et al. Expires April 20, 2006 [Page 10] Internet-Draft MIP4 Generic Notification Message October 2005 Set to "0" to request this message going to foreign agent. Reserved MUST be sent as 0, ignored when received. Home Address The home IP address of the mobile node. Home Agent / Foreign Agent Address The IP address of the sender, home agent or foreign agent. 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 There are two possiblities that the mobile node MAY receive a generic notifcation message from a foreign agent or home agent. Both in the case of FA-CoA and Co-located CoA, mobile node MAY optionally reply Generic Notification Acknowledgement message based on the flag "A" in the notification message. 4.3.1. Receiving Generic Notification Messages In the case of FA-CoA, if mobile node received this message, and flag "H" is set to "1", it means that notification message come from home agent, otherwise from foreign agent. Deng, et al. Expires April 20, 2006 [Page 11] Internet-Draft MIP4 Generic Notification Message October 2005 Anyway Mobile-Foreign Authentication extension MUST be checked, 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 come from foreign agent and mobile node accepts the foreign agent's generic notification message, it will process the notification extension or various extension such as string generic string extension. After that, mobile node MAY optionally reply Generic Notifcation Acknowledgement message back to the foreign agent. if the flag "A" is set in the notification message requiring an acknowledgement, then the mobile node must send the acknowledgement. If this notification message come from home agent relayed by foreign agent or in the case of Co-located CoA, Mobile-Home Authentication extension MUST be checked, 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 mobile node accepts the home agent's generic notification message, it will process based on the the notification extension or various extension such as string generic string extension. After that, mobile node MAY optionally reply Generic Notifcation Acknowledgement message back to the home agent based on the flag "A" in the notification message. 4.3.2. Sending Generic Notification Acknowledgement Message Both in the case of Co-located CoA and FA-CoA , the mobile node MAY optionally reply Generic Notification Acknowledgement Message based on the flag "A" in the notification message which is defined as follows: In the case of FA-CoA, The source address is mobile node address, the destination address is foreign agent address, If the notification message is initated from foreign agent to mobile node , flag "M" is set to "1", flag "H" 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 Authentication extension defined in section 3.5.3 of [RFC3344]. If the notification message is initated from home agent to mobile node , flag "M" is set to "1", flag "H" is set to "1", The ordering Deng, et al. Expires April 20, 2006 [Page 12] Internet-Draft MIP4 Generic Notification Message October 2005 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 FA-CoA, The source address is mobile node CoA address, the destination address is home agent address, flag "M" is set to "1", flag "H" 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 Mobile-Home Authentication Extension defined in section 3.5.2. of [RFC3344]. 4.4. Foreign Agent Consideration Foreign agent not only could relay generic notification message from home agent and generic notification acknowledgement message from mobile node, but also could initiate generic notification message to mobile node and home agent. But only when there is a binding for a mobile node. It can send the message to the mobile node or to th home agent. This means that the messaging is between the entities in the binding relation. 4.4.1. Receiving Generic Notification Message If foreign agent received a notification message, and flag "M" is set to "1", it means that home agent ask foreign agent relay generic notification message to mobile nodeGBP[not] otherwise, it means that home agent notify foreign agent only. In the case of flag "M" is set to "0", firstly, the Foreign-Home Authentication extension MUST be checked, 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 based on the notification extension or various extension such as string generic string extension. After that, foreign agent MAY optionally reply Generic Notifcation Acknowledgement message back to the home agent based on the flag "A" in the notification message. In the case of flag "M" is set to "1", firstly, the Foreign-Home Authentication extension MUST be checked, 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 Deng, et al. Expires April 20, 2006 [Page 13] Internet-Draft MIP4 Generic Notification Message October 2005 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 Notfication. The foreign agent MUST NOT modify any of the fields beginning with the fixed portion of the Generic Notifcation 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. And, foreign agent MUST process and remove any Extensions following the Mobile-Home Authentication Extension, 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 Both in the case of mobile node reply generic notification acknowledgement message to home agent throuth foreign agent and home agent notify only forieng agent, the forieng agent MUST relay or MAY optionally reply Generic Notification Acknowledgement Message which is defined as follows: The source address is foreign agent address, the destination address is home agent address, If foreign agent only relay this message to home agent, the foreign agent MUST NOT modify any of the fields beginning with the fixed portion of the Generic Notifcation 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. And, foreign agent MUST process and remove any Extensions following the Mobile- Home Authentication Extension, MAY append any of its own non- authentication Extensions of relevance to the home agent, if applicable, and MUST append the Foreign-Home Authentication Extension, if the foreign agent shares a mobility security association with the home agent. If the notification message is only sent from home agent to foreign agent then flag "M" is set to "0", flag "H" is set to "1", 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 April 20, 2006 [Page 14] Internet-Draft MIP4 Generic Notification Message October 2005 4.4.3. Sending Generic Notification Message If foreign agent would like to initiate notifing mobile node something using the generic notifcation message, for example, AAAF would like to notify mobile node. In this case foreign agent MAY notify both mobile node and home agent. In the message to mobile node is defined as: The source address is foreign agent address, the destination address is mobile node address, flag "M" is set to "1", flag "H" is set to "0", The ordering of the extension is: the notification extension or various extension such as string generic string 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 home agent is defined as: The source address is foreign agent address, the destination address is home agent address, flag "M" is set to "0", flag "H" is set to "0", The ordering of the extension is: notification extension or various extension such as string generic string 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 generic notification message to both mobile node and forieng agent, and also it MAY received generic notification acknowledgement message both from foreign agent and mobile node, lastly home agent also MAY receive generic notification message from foreign agent. Only when there is a binding for a mobile node. It can send the message to the mobile node or to th registered foreign agent in the path. So, the messaging is between the entities in the binding relation. if there are no registration existed, notification from foreign agent to home agent should be dropped 4.5.1. Sending Generic Notification Message In the case of FA CoA, there are two possiblities that home agent notify foreign agent, one is home agent notify foreign agent only, the other is home agent ask foreign agent working as relay to mobile node Deng, et al. Expires April 20, 2006 [Page 15] Internet-Draft MIP4 Generic Notification Message October 2005 Anyway in the message from home agnet to foreign agent, the source address is home agent address, the destination address is foreign agent address In the case of foreign agent work as only a relay agent: flag "M" is set to "1", flag "H" is set to "1", The ordering of the extension is: the notification extension or various extension such as string generic string 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]. In the case of foreign agent work as the final receiver of this notification message, then in this notification message: flag "M" is set to "0", flag "H" is set to "1", The ordering of the extension is: the notification extension or various extension such as string generic string 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 home agent received this message, and flag "M" is set to "1", it means that notification acknowledgement message come from mobile node, otherwise from foreign agent. 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 Acknowledgement message. In the case of flag "M" is set to "0", if home agent accepted this message, For all Generic Notification Acknowledgement messages containing a Status Code indicating status from the Foreign Agent, If the Status field indicates that the notification was accepted by the foreign agent, home agent MAY also process based on notification event. In the case of flag "M" is set to "0", if home agent accepted this message, the Mobile-Home Authentication extension MUST be checked, the home agent MUST check the Authenticator value in the Extension. If no Mobile-Home Authentication Extension is found, or if more than Deng, et al. Expires April 20, 2006 [Page 16] Internet-Draft MIP4 Generic Notification Message October 2005 one Mobile-Home Authentication Extension is found, or if the Authenticator is invalid, the home agent MUST silently discard the Notification Acknowledgement message. if home agent accepted this 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 also process based on notification event. In the case of Co-located CoA, if home agent received this message, the Mobile-Home Authentication extension MUST be checked, 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 based on notification event. 4.5.3. Receiving Generic Notification Messages Home agent MAY receive generic notification message which is sent from foreign agent. If home agent received this message, 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 based on the notification extension or various extension such as string generic string extension. After that, home agent MAY optionally reply Generic Notifcation Acknowledgement message back to the foreign agent based on the flag "A" in the notification message. 4.5.4. Sending Generic Notification Acknowledgement Message If the generic notification message initiately come from foreign agent only. home agent MAY optionally reply a generic notification acknowledgement message to foreign agent based on the flag "A" in the notification message. if the flag "A" is set in the notification message requiring an acknowledgement, then the mobile node must send the notificaiton acknowledgement message. The message is defined as follows: The source address is home agent address, the destination address is foreign agent address, flag "M" is set to "0", flag "H" is set to "0", The ordering of the extension is: any non-authentication Extensions used only by the foreign agent, followed by The Foreign- Deng, et al. Expires April 20, 2006 [Page 17] Internet-Draft MIP4 Generic Notification Message October 2005 Home Authentication extension defined in section 3.5.4 of [RFC3344]. Deng, et al. Expires April 20, 2006 [Page 18] Internet-Draft MIP4 Generic Notification Message October 2005 5. Usage Example There are several applications could use this generic notification message for example, during handover between CDMA 2000 1x EV-DO and Wireless LAN, PPP resource of CDMA side have to be removed, this notification from home agent to foreign agent (PDSN) is also very useful to avoid over-charging subscribers. Here we give a example of using revocation extension and describe some possbile event which could use generic string extension based on this notification mechanism also. There are also possbilities, that this notification message could carry many extensions 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 generic notification message ane generic notification acknowledgement also, only just specifiy 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, home agent or foreign agent also need notify mobile node about service termination due to end of prepaid time, or service interruption due to system maintenance. those information could be defined based on string which is recognized by mobile node easily. Here give examples "Maintenance Stop", "Prepaid Expire". Anyway those string MUST be defined strictly which could be easily understand by all of the network entities. "Subtype" number will be decied by working group. Deng, et al. Expires April 20, 2006 [Page 19] Internet-Draft MIP4 Generic Notification Message October 2005 6. Security Considerations Mobile IP Generic Notification and Generic Notification Acknowledgement are authenticated, and the authentication verified by the recipient. Deng, et al. Expires April 20, 2006 [Page 20] Internet-Draft MIP4 Generic Notification Message October 2005 7. IANA Considerations This document defines an additional set of messages among home agent, foreign agent, and mobile node specific to the services being provided to the same mobile node, or sub-set of mobile nodes. To ensure correct interoperation based on this specification, IANA has reserved values in the Mobile IP number space for two new message types. 7.1. New Message Types The following message types are introduced by this specification: Generic Notification: A new Mobile IP control message. This value has been taken from the same number space as Mobile IP Registration Request (Type = 1), and Mobile IP Registration Reply (Type = 3). Generic Notification Acknowledgment: A new Mobile IP control message. This value has been taken from the same number space as Mobile IP Registration Request (Type = 1), and Mobile IP Registration Reply (Type = 3). 8. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/ Response Extensions", RFC 3012, November 2000. [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. Deng, et al. Expires April 20, 2006 [Page 21] Internet-Draft MIP4 Generic Notification Message October 2005 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 Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Email: vijay.devarapalli@nokia.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 April 20, 2006 [Page 22] Internet-Draft MIP4 Generic Notification Message October 2005 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 (2005). 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 April 20, 2006 [Page 23]