MIP4 Working Group                                               H. Deng
Internet-Draft                                              China Mobile
Intended status: Standards Track                            H. Levkowetz
Expires: January 15, 2009                              Ericsson Research
                                                          V. Devarapalli
                                                                WiChorus
                                                           S. Gundavelli
                                                           Cisco Systems
                                                                B. Haley
                                                 Hewlett-Packard Company
                                                           July 14, 2008


              Generic Notification Message for Mobile IPv4
          draft-ietf-mip4-generic-notification-message-06.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 January 15, 2009.











Deng, et al.            Expires January 15, 2009                [Page 1]


Internet-Draft      MIP4 Generic Notification Message          July 2008


Abstract

   This document specifies protocol enhancements that allow Mobile IPv4
   entities to send and receive explicit notification messages using a
   new Mobile IPv4 message type designed for this purpose.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Notification message - Usage Scenario's  . . . . . . . . . . .  6
     3.1.  Notification message from a Home Agent to a Mobile Node  .  6
       3.1.1.  Mobile Registered using a Foreign Agent Care-of
               Address  . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.2.  Mobile Registered using a Co-located Care-of
               Address  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Notification message from a Foreign Agent to a Mobile
           Node . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Notification message from a Home Agent to a Foreign
           Agent  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Generic Notification Message and Considerations  . . . . . . .  8
     4.1.  Generic Notification Message . . . . . . . . . . . . . . .  8
     4.2.  Generic Notification Acknowledgment Message  . . . . . . . 10
     4.3.  Mobile Node Consideration  . . . . . . . . . . . . . . . . 13
       4.3.1.  Receiving Generic Notification Messages  . . . . . . . 13
       4.3.2.  Sending Generic Notification Acknowledgement
               Message  . . . . . . . . . . . . . . . . . . . . . . . 14
     4.4.  Foreign Agent Consideration  . . . . . . . . . . . . . . . 15
       4.4.1.  Receiving Generic Notification Message . . . . . . . . 15
       4.4.2.  Sending Generic Notification Acknowledgement
               Messages . . . . . . . . . . . . . . . . . . . . . . . 16
       4.4.3.  Sending Generic Notification Messages  . . . . . . . . 16
       4.4.4.  Receiving Generic Notification Acknowledgement
               Messages . . . . . . . . . . . . . . . . . . . . . . . 17
     4.5.  Home Agent Consideration . . . . . . . . . . . . . . . . . 18
       4.5.1.  Sending Generic Notification Messages  . . . . . . . . 18
       4.5.2.  Receiving Generic Notification Acknowledgement
               Messages . . . . . . . . . . . . . . . . . . . . . . . 19
       4.5.3.  Receiving Generic Notification Messages  . . . . . . . 19
       4.5.4.  Sending Generic Notification Acknowledgement
               Messages . . . . . . . . . . . . . . . . . . . . . . . 20
   5.  Usage Example  . . . . . . . . . . . . . . . . . . . . . . . . 22
     5.1.  Revocation Extension . . . . . . . . . . . . . . . . . . . 22
     5.2.  Generic String Extension . . . . . . . . . . . . . . . . . 22
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 25



Deng, et al.            Expires January 15, 2009                [Page 2]


Internet-Draft      MIP4 Generic Notification Message          July 2008


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
   Intellectual Property and Copyright Statements . . . . . . . . . . 27

















































Deng, et al.            Expires January 15, 2009                [Page 3]


Internet-Draft      MIP4 Generic Notification Message          July 2008


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 messages 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 January 15, 2009                [Page 4]


Internet-Draft      MIP4 Generic Notification Message          July 2008


2.  Terminology

   It is assumed that the reader is familiar with the terminology used
   in [RFC3543], [RFC4917], [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 RFC 2119, [RFC2119].




































Deng, et al.            Expires January 15, 2009                [Page 5]


Internet-Draft      MIP4 Generic Notification Message          July 2008


3.  Notification message - Usage Scenario's

   There are several scenarios where a mobility agent could initiate
   notification events.  Some of these are described in the following
   sections.

3.1.  Notification message from a Home Agent to a Mobile Node

3.1.1.  Mobile Registered using a 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.  Mobile Registered using a 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

3.2.  Notification message from a Foreign Agent to a 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.



Deng, et al.            Expires January 15, 2009                [Page 6]


Internet-Draft      MIP4 Generic Notification Message          July 2008


   +----+    notification +----+ notification +--------+
   | MN |<================| FA |<=============|   AAA  |
   +----+                 +----+              +--------+
                            ||   notification +----+
                             ================>| HA |
                                              +----+


               Figure 3: Foreign Agent notifies Mobile Node

3.3.  Notification message from a Home Agent to a 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 January 15, 2009                [Page 7]


Internet-Draft      MIP4 Generic Notification Message          July 2008


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
   such as vendor specific extensions, generic string notification or
   binding revocation.  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     |      MD       |A|  Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Home Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Home Agent Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Care-of Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                       Identification                          +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Extensions...
      +-+-+-+-+-+-+-+-+-+-+-+-+-



Deng, et al.            Expires January 15, 2009                [Page 8]


Internet-Draft      MIP4 Generic Notification Message          July 2008


   Type (TBD)

   Subtype

      This field describes the particular type of notification which is
      carried in the notification message.  The following values are
      reserved in this document.

      0 Reserved

      1 Information carried in Vendor specific extensions

      2 Information carried in Generic String extensions

      3 Information carried in Binding Revocation extension

      The value 0 is reserved and should not be used.  The value 1
      indicates that the actual information is carried in vendor
      specific extensions.  Other values are reserved for future
      extensions.

   MD: Message Direction

      This memo defines the semantics of the following MD field value:

      0 -- Message sent by the home agent to the mobile node

      1 -- Message sent by the home agent to the foreign agent

      2 -- Message sent by the mobile node to the home agent

      3 -- Message sent by the mobile node to the foreign agent

      4 -- Message sent by the foreign agent to the mobile node

      5 -- Message sent by the foreing agent to the home 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




Deng, et al.            Expires January 15, 2009                [Page 9]


Internet-Draft      MIP4 Generic Notification Message          July 2008


      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.

   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.  Here is the same as Sections 5.4 and 5.7 of [RFC3344].
      Timestamps is mandatory and nonces is optional.

   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].  This document mandate the MN-HA AE when this
      message is sent between the mobile node and the home agent, others
      are optional.  This document also mandate the MN-FA AE when this
      message is sent between the mobile node and the foreign agent,
      others are optional.  This document mandate the FA-HA AE when this
      message is sent between the foreign agent and the home agent,
      others are optional.  This could be judged based on "MD" value.).
      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:





Deng, et al.            Expires January 15, 2009               [Page 10]


Internet-Draft      MIP4 Generic Notification Message          July 2008


     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:

    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     |      MD       |    Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Home Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Home Agent Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Care-of Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Identification                          +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Extensions...
   +-+-+-+-+-+-+-+-+-+-+-+-+-


   Type (TBD)

   Subtype

      This field specifies the particular type of notification
      acknowledgement message.  The following values are reserved in
      this document.

      0 Reserved

      1 Information carried in Vendor specific extensions




Deng, et al.            Expires January 15, 2009               [Page 11]


Internet-Draft      MIP4 Generic Notification Message          July 2008


      2 Information carried in Generic String extensions

      3 Information carried in Binding Revocation extension

      The value 0 is reserved and should not be used.  The value 1
      indicates that the actual information is carried in vendor
      specific extensions.  Other values are reserved for future
      extensions.

   MD: Message Direction

      This memo defines the semantics of the following MD field value:

      0 -- Message sent by the home agent to the mobile node

      1 -- Message sent by the home agent to the foreign agent

      2 -- Message sent by the mobile node to the home agent

      3 -- Message sent by the mobile node to the foreign agent

      4 -- Message sent by the foreign agent to the mobile node

      5 -- Message sent by the foreing agent to the home agent

   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 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

      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].  This document mandate the MN-HA AE when this



Deng, et al.            Expires January 15, 2009               [Page 12]


Internet-Draft      MIP4 Generic Notification Message          July 2008


      message is sent between the mobile node and the home agent, others
      are optional.  This document also mandate the MN-FA AE when this
      message is sent between the mobile node and the foreign agent,
      others are optional.  This document mandate the FA-HA AE when this
      message is sent between the foreign agent and the home agent,
      others are optional.  This could be judged based on "MD" value.).
      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.

   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.

4.3.1.  Receiving Generic Notification Messages

   When the mobile node is using FA-CoA and receives a Notification
   message, if the "MD" value is 0, it means that the notification
   message came from the home agent.  If the "MD" value is 4, the
   notification came from the foreign agent.

   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.

   The MN MUST check for the presence of an authorization-enabling
   extension, and perform the indicated authentication.  Exactly one
   authorization-enabling extension MUST be present in the Registration
   Request, if this message came from a foreign agent, MN-FA AE MUST be
   present, if this message came from a foreign agent, MN-HA AE MUST be
   present.

   After that, the mobile node MAY reply with a Generic Notification
   Acknowledgement message back to the foreign agent.  If the "A" flag



Deng, et al.            Expires January 15, 2009               [Page 13]


Internet-Draft      MIP4 Generic Notification Message          July 2008


   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:

   If the notification message was initiated from the foreign agent to
   the mobile node ("MD" value is set to 4), 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].

   In the case of a FA-CoA, the source address is the mobile node's
   address, the destination address is the foreign agent's address.

   If the notification message was initiated from the home agent to the
   mobile node ("MD" value is set to 0) and in the case of Co-located
   CoA, the ordering of the extension is: 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 ("MD"
   value is set to 2), the ordering of the extension is: 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], followed by 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].






Deng, et al.            Expires January 15, 2009               [Page 14]


Internet-Draft      MIP4 Generic Notification Message          July 2008


4.4.  Foreign Agent Consideration

   The foreign agent can not 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, and it
   will depends on whether there is a binding for the mobile node.

4.4.1.  Receiving Generic Notification Message

   If the foreign agent receives a notification message, and the "MD"
   value is set to 0, it means that the home agent is asking the foreign
   agent to relay the message to the mobile node.  If the "MD" value is
   set to 1, it means that the target of the notification is the foreign
   agent.

   If the "MD" value is set to 1, the Foreign-Home Authentication
   extension MUST be checked, and the foreign agent MUST check the
   Authenticator value in the Extension which is the same as the section
   3.7.3.1 of RFC 3344.  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 "MD" value is set to 0, the foreign agent MUST check the FA-HA
   AE and Authenticator value in the Extension if the Foreign-Home
   Authentication extension is presented. 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 the foreign agent validates 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.



Deng, et al.            Expires January 15, 2009               [Page 15]


Internet-Draft      MIP4 Generic Notification Message          July 2008


4.4.2.  Sending Generic Notification Acknowledgement Messages

   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 the "MD" value 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].

4.4.3.  Sending Generic Notification Messages

   If the foreign agent is initiating a notification to 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 "MD" value is set to 4, 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 Value 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



Deng, et al.            Expires January 15, 2009               [Page 16]


Internet-Draft      MIP4 Generic Notification Message          July 2008


   (the "MD" value is set to 5), and 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 Value is the same as section 3.5.1
   of [RFC3344] except the payload is the notification other than
   registration.

4.4.4.  Receiving Generic Notification Acknowledgement Messages

   In the case of a FA-CoA, if the foreign agent receives this message,
   and the "MD" value is set to 3, it means that the notification
   acknowledgement message came from the mobile node, otherwise it came
   from the home agent.

   If the "MD" value is set to 1, 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
   Acknowledgement message.  If the foreign agent accepted this message,
   the foreign agent MAY also process it based on the notification
   event.

   If the "MD" value is set to 3, if the Mobile-Foreign Authentication
   extension is presented, it MUST be checked, and the foreign agent
   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 foreign agent MUST silently discard the
   Notification Acknowledgement message.  If the foreign agent accepted
   this message, the foreign agent MAY also process it based on the
   notification event.

   In the case of a FA-CoA and if the "MD" value is set to 2, if the
   foreign agent received this message, the Mobile-Foreign
   Authentication extension MUST be checked, and the foreign agent 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 foreign agent MUST silently discard the Notification
   Acknowledgement message.  If foreign agent accepted the mobile node's
   Generic Notification Acknowledgement message, it MUST relay this
   message to the home agent.  The foreign agent MUST NOT modify any of
   the fields beginning with the fixed portion of the Generic
   Notification Acknowledgement message through and including the
   Mobile-Home Authentication Extension or other authentication



Deng, et al.            Expires January 15, 2009               [Page 17]


Internet-Draft      MIP4 Generic Notification Message          July 2008


   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, and MUST append the Foreign-Home Authentication
   Extension, if the foreign agent shares a mobility security
   association with the home agent.

4.5.  Home Agent Consideration

   The 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.  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 Messages

   In the case of a 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 be notified.

   If the message is from the home agent to the foreign agent, the
   source address is the home agent's address, and the destination
   address is the foreign agent's address

   If the foreign agent is working only as a relay agent, the "MD" value
   is set to 0, 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 Value
   is the same as section 3.5.1 of [RFC3344].

   If the foreign agent is the target of this notification message, then
   the "MD" value is set to 1, and 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 Value is the same as section 3.5.1
   of [RFC3344].



Deng, et al.            Expires January 15, 2009               [Page 18]


Internet-Draft      MIP4 Generic Notification Message          July 2008


   In the case of a Co-located CoA, the home agent MAY send a
   notification message directly to the mobile node if it needs to be
   notified.  The "MD" value is set to 0, 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].

4.5.2.  Receiving Generic Notification Acknowledgement Messages

   In the case of a FA-CoA, if the home agent receives this message, and
   the "MD" value is set to 2, it means that the notification
   acknowledgement message came from mobile node.

   If the "MD" value is set to 5, and the home agent accepted this
   message, the home agent MAY also process it based on the notification
   event.  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 "MD" value is set to 2, 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,
   the home agent MAY also process it based on the notification event.

   In the case of a 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.

4.5.3.  Receiving Generic Notification Messages

   The home agent MAY receive a generic notification message sent from
   the foreign agent.  When the home agent receives this message, if the
   the "MD" value is set to 5, this message came from foreign agent.
   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



Deng, et al.            Expires January 15, 2009               [Page 19]


Internet-Draft      MIP4 Generic Notification Message          July 2008


   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.

   if the the "MD" value is set to 2, this message come from mobile
   node, if Foreign-Home Authentication extension is presented, it MUST
   be checked, and the home agent MUST check the Authenticator value in
   the Extension. 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.  And 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
   message.  If home agent accepts the mobile node'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 "MD" value is set to 1.  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].

   If the generic notification message came from the mobile node, the
   home agent MAY reply with a generic notification acknowledgement
   message to the mobile node 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 "MD"
   value is set to 0.  The ordering of the extension is: any non-
   authentication Extensions used only by the mobile node, followed by



Deng, et al.            Expires January 15, 2009               [Page 20]


Internet-Draft      MIP4 Generic Notification Message          July 2008


   the Mobile-Home Authentication Extension defined in section 3.5.2. of
   [RFC3344], optionly followed by any non-authentication Extensions
   used only by the foreign agent, optionly followed by The Mobile-
   Foreign Authentication extension defined in section 3.5.3 of
   [RFC3344]














































Deng, et al.            Expires January 15, 2009               [Page 21]


Internet-Draft      MIP4 Generic Notification Message          July 2008


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, service or billing
   related events, 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, and service interruption due
   to system maintenance.

   Here we give a example of using revocation extension and describe
   some possible event which could use the generic string extension
   [RFC4917]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 one agent wants to notify another agent about registration
   revocation [RFC3543], it could easily be carried by a generic
   notification message and generic notification acknowledgement by
   specifying the exact "Subtype" in the two messages which will request
   IANA for approvement.Besides that, the home address, foreign domain
   address, and home domain address are already specified in the
   notificaiton message and the notification acknowledgement message.

5.2.  Generic String Extension

   In some case, the home agent or foreign agent needs to notify the
   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 [RFC4917]which is recognized by
   the 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 would need to be decided by the working group.











Deng, et al.            Expires January 15, 2009               [Page 22]


Internet-Draft      MIP4 Generic Notification Message          July 2008


6.  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].  The subtype of these two
   messages indicate what kind of information is carried and will be
   under assigned by IANA namespace.

   This document creates a new IANA registry for the Subtype field In
   the Generic Notification and Generic Notification Acknowledgement
   messages.  New values should be allocated by Standards Actions or
   IETF Consensus.  This document reserves four values for the Subtype
   field

   0 Reserved

   1 Information carried in Vendor specific extensions

   2 Information carried in Generic String Extension

   3 Information carried in Revocation extensions




























Deng, et al.            Expires January 15, 2009               [Page 23]


Internet-Draft      MIP4 Generic Notification Message          July 2008


7.  Security Considerations

   This specification operates in the security constraints and
   requirements of [RFC3344].  It require that when this message is
   transmitted between the mobile node and the home agent, MN-HA AE is
   mandatory, when this message is transmitted between the mobile node
   and the foreign agent, MN-FA AE is mandatory, when this message is
   transmitted between the foreign agent and the home agent, FA-HA AE is
   mandatory.  It extends the operations of mobile node, home agent and
   foreign agent defined in [RFC3344] to notify each other about some
   events.  The Generic Notification message defined in the
   specification could carry information that modifies the mobility
   bindings.  Therefore the message MUST be integrity protected.  Replay
   protection MUST also be guaranteed.

   RFC 3344 provides replay protection only for registration requests
   sent by the mobile node.  There is no mechanism for replay protection
   for messages initiated by a Foreign Agent.  The 64-bit Identification
   field specified in this document (Section 4.1 and 4.2) for the
   Generic Notification message is used to provide replay protection for
   the notification messages initiated by the Foreign Agent.






























Deng, et al.            Expires January 15, 2009               [Page 24]


Internet-Draft      MIP4 Generic Notification Message          July 2008


8.  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.

   [RFC4917]  Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message
              String Extension", RFC 4917, June 2007.






































Deng, et al.            Expires January 15, 2009               [Page 25]


Internet-Draft      MIP4 Generic Notification Message          July 2008


Authors' Addresses

   Hui Deng
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: denghui02@gmail.com


   Henrik Levkowetz
   Ericsson Research
   Torshamsgatan 23
   S-164 80, Stockholm
   SWEDEN

   Email: henrik@levkowetz.com


   Vijay Devarapalli
   WiChorus
   3590 North First St
   San Jose, CA
   USA

   Email: dvijay@gmail.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 January 15, 2009               [Page 26]


Internet-Draft      MIP4 Generic Notification Message          July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.











Deng, et al.            Expires January 15, 2009               [Page 27]