MIP4 Working Group H. Deng
Internet-Draft Hitachi (China)
Expires: September 6, 2006 H. Levkowetz
Ericsson Research
V. Devarapalli
Nokia Research Center
S. Gundavelli
Cisco Systems
B. Haley
Hewlett-Packard Company
March 5, 2006
Generic Notification Message for Mobile IPv4
draft-deng-mip4-generic-notification-message-01.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 September 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies protocol enhancements that allow Mobile IPv4
Deng, et al. Expires September 6, 2006 [Page 1]
Internet-Draft MIP4 Generic Notification Message March 2006
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 . . . . . . . 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 Message . . . . . . . . . 15
4.5. Home Agent Consideration . . . . . . . . . . . . . . . . . 15
4.5.1. Sending Generic Notification Message . . . . . . . . . 16
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
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Deng, et al. Expires September 6, 2006 [Page 2]
Internet-Draft MIP4 Generic Notification Message March 2006
1. Introduction
In some situations, there is a need for 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 defines a generic message and a notification model that
can be used by the 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 messages. Specific
extensions and the corresponding handler actions are outside the
scope of this document.
Deng, et al. Expires September 6, 2006 [Page 3]
Internet-Draft MIP4 Generic Notification Message March 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 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 September 6, 2006 [Page 4]
Internet-Draft MIP4 Generic Notification Message March 2006
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 notifies 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 notifies 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 September 6, 2006 [Page 5]
Internet-Draft MIP4 Generic Notification Message March 2006
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
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 September 6, 2006 [Page 6]
Internet-Draft MIP4 Generic Notification Message March 2006
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 MIP-related information.
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 September 6, 2006 [Page 7]
Internet-Draft MIP4 Generic Notification Message March 2006
Subtype
This field describes the particular type notification which is
carried in the notification message.
M
This bit identifies whether the receiver of the notification is a
mobile node
Set to "1" if the message is intended for the mobile node.
Set to "0" if the message is not intended for the 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 September 6, 2006 [Page 8]
Internet-Draft MIP4 Generic Notification Message March 2006
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 September 6, 2006 [Page 9]
Internet-Draft MIP4 Generic Notification Message March 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 describes the particular type notiifcation which is
carried in the Notification field.
M
This bit identifies the sender of this message is 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 receiver of this notification
acknowledgement is home agent or not.
Set to "1" to indicate the receiver is home agent.
Set to "0" to indicate the receiver is not home agent.
Reserved
MUST be sent as 0, ignored when received.
Deng, et al. Expires September 6, 2006 [Page 10]
Internet-Draft MIP4 Generic Notification Message March 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, home agent.
Care-of Address
The IP address for the end of the tunnel.
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.
Deng, et al. Expires September 6, 2006 [Page 11]
Internet-Draft MIP4 Generic Notification Message March 2006
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.
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
Deng, et al. Expires September 6, 2006 [Page 12]
Internet-Draft MIP4 Generic Notification Message March 2006
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
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
Deng, et al. Expires September 6, 2006 [Page 13]
Internet-Draft MIP4 Generic Notification Message March 2006
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
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
Deng, et al. Expires September 6, 2006 [Page 14]
Internet-Draft MIP4 Generic Notification Message March 2006
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].
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
Deng, et al. Expires September 6, 2006 [Page 15]
Internet-Draft MIP4 Generic Notification Message March 2006
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
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
Deng, et al. Expires September 6, 2006 [Page 16]
Internet-Draft MIP4 Generic Notification Message March 2006
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
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
Deng, et al. Expires September 6, 2006 [Page 17]
Internet-Draft MIP4 Generic Notification Message March 2006
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-
Home Authentication extension defined in section 3.5.4 of [RFC3344].
Deng, et al. Expires September 6, 2006 [Page 18]
Internet-Draft MIP4 Generic Notification Message March 2006
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. Other applications such
as registration revocation, home agent switch over, potential NEMO
prefix related (assuming the NEMOv4 draft will go through, and
service and billing related events.
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 September 6, 2006 [Page 19]
Internet-Draft MIP4 Generic Notification Message March 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 September 6, 2006 [Page 20]
Internet-Draft MIP4 Generic Notification Message March 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]
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 September 6, 2006 [Page 21]
Internet-Draft MIP4 Generic Notification Message March 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
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 September 6, 2006 [Page 22]
Internet-Draft MIP4 Generic Notification Message March 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 September 6, 2006 [Page 23]