MIP4 Working Group H. Deng
Internet-Draft China Mobile
Intended status: Standards Track H. Levkowetz
Expires: August 15, 2008 Ericsson Research
V. Devarapalli
Azaire Networks
S. Gundavelli
Cisco Systems
B. Haley
Hewlett-Packard Company
February 12, 2008
Generic Notification Message for Mobile IPv4
draft-ietf-mip4-generic-notification-message-03.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 August 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Deng, et al. Expires August 15, 2008 [Page 1]
Internet-Draft MIP4 Generic Notification Message February 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 . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Foreign Agent Consideration . . . . . . . . . . . . . . . 14
4.4.1. Receiving Generic Notification Message . . . . . . . . 14
4.4.2. Sending Generic Notification Acknowledgement
Messages . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.3. Sending Generic Notification Messages . . . . . . . . 16
4.4.4. Receiving Generic Notification Acknowledgement
Messages . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Home Agent Consideration . . . . . . . . . . . . . . . . . 17
4.5.1. Sending Generic Notification Messages . . . . . . . . 17
4.5.2. Receiving Generic Notification Acknowledgement
Messages . . . . . . . . . . . . . . . . . . . . . . . 18
4.5.3. Receiving Generic Notification Messages . . . . . . . 19
4.5.4. Sending Generic Notification Acknowledgement
Messages . . . . . . . . . . . . . . . . . . . . . . . 19
5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Revocation Extension . . . . . . . . . . . . . . . . . . . 20
5.2. Generic String Extension . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Normative References . . . . . . . . . . . . . . . . . . . . . 23
Deng, et al. Expires August 15, 2008 [Page 2]
Internet-Draft MIP4 Generic Notification Message February 2008
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Deng, et al. Expires August 15, 2008 [Page 3]
Internet-Draft MIP4 Generic Notification Message February 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 August 15, 2008 [Page 4]
Internet-Draft MIP4 Generic Notification Message February 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 August 15, 2008 [Page 5]
Internet-Draft MIP4 Generic Notification Message February 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 August 15, 2008 [Page 6]
Internet-Draft MIP4 Generic Notification Message February 2008
+----+ notification +----+ notification +--------+
| MN |<================| FA |<=============| AAA/HA |
+----+ +----+ +--------+
|| 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 August 15, 2008 [Page 7]
Internet-Draft MIP4 Generic Notification Message February 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.
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 August 15, 2008 [Page 8]
Internet-Draft MIP4 Generic Notification Message February 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
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
MUST be sent as 0, and ignored when received.
Home Address
Deng, et al. Expires August 15, 2008 [Page 9]
Internet-Draft MIP4 Generic Notification Message February 2008
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. See Sections 5.4 and 5.7 of [RFC3344].
Extensions
The fixed portion of the Generic Notification Message is followed
by one or more extensions which may be used with this message, and
by one or more authentication extensions (as defined in Section
3.5 of [RFC3344]). See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344]
for information on the relative order in which different
extensions, when present, must be placed in a Generic Notification
Message.
4.2. Generic Notification Acknowledgment Message
A generic notification acknowledgement message is sent by mobility
agents or mobile nodes to indicate the successful receipt of a
generic notification message.
IP Fields:
Source Address Typically copied from the destination
address of the Generic Notification to which
the agent is replying.
Destination Address Copied from the source address of the
Generic Notification to which the agent is
replying.
UDP Fields:
Deng, et al. Expires August 15, 2008 [Page 10]
Internet-Draft MIP4 Generic Notification Message February 2008
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
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:
Deng, et al. Expires August 15, 2008 [Page 11]
Internet-Draft MIP4 Generic Notification Message February 2008
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
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
Deng, et al. Expires August 15, 2008 [Page 12]
Internet-Draft MIP4 Generic Notification Message February 2008
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. After that, the mobile node MAY reply with
a Generic Notification Acknowledgement message back to the foreign
agent. If the "A" flag is set in the notification message, then the
mobile node MUST send the acknowledgement.
If this notification message came from the home agent, relayed by the
foreign agent, or is a Co-located CoA, the Mobile-Home Authentication
extension MUST be checked and the mobile node MUST check the
Authenticator value in the Extension. If no Mobile-Home
Authentication Extension is found, or if more than one Mobile-Home
Authentication Extension is found, or if the Authenticator is
invalid, the mobile node MUST silently discard the Notification
message. If the mobile node accepts the home agent's generic
notification message, it will process it according to the specific
rules for that extension. After that, the mobile node MAY reply with
a Generic Notification Acknowledgement message back to the home agent
based on the "A" flag in the notification message.
4.3.2. Sending Generic Notification Acknowledgement Message
Both in the case of a Co-located CoA and FA-CoA, the mobile node MAY
reply with a Generic Notification Acknowledgement Message based on
the "A" flag in the notification message as follows:
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
Deng, et al. Expires August 15, 2008 [Page 13]
Internet-Draft MIP4 Generic Notification Message February 2008
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].
4.4. Foreign Agent Consideration
The foreign agent cannot only relay generic notification message from
the home agent and mobile node, but it can also initiate a generic
notification message to the mobile node or home agent, but only when
there is a binding for the mobile node.
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. Otherwise, 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. 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-Home Authentication
extension MUST be checked, and the foreign agent MUST check the
Deng, et al. Expires August 15, 2008 [Page 14]
Internet-Draft MIP4 Generic Notification Message February 2008
Authenticator value in the Extension. If no Foreign-Home
Authentication Extension is found, or if more than one Foreign-Home
Authentication Extension is found, or if the Authenticator is
invalid, the foreign agent MUST silently discard the Notification
message. If foreign agent accepts the home agent's generic
notification message, it MUST relay the Generic Notification to the
mobile node's home address as specified in the Home Address field of
the Generic Notification. The foreign agent MUST NOT modify any of
the fields beginning with the fixed portion of the Generic
Notification message through and including the Mobile-Home
Authentication Extension or other authentication extension supplied
by the home agent as an authorization-enabling extension for the
mobile node. Furthermore, the foreign agent MUST process and remove
any Extensions following the Mobile-Home Authentication Extension and
MAY append any of its own non-authentication Extensions of relevance
to the mobile node, if applicable, and MUST append the Mobile-Foreign
Authentication Extension, if the foreign agent shares a mobility
security association with the Mobile Node.
4.4.2. Sending Generic Notification Acknowledgement 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].
Deng, et al. Expires August 15, 2008 [Page 15]
Internet-Draft MIP4 Generic Notification Message February 2008
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
(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, and the foreign agent accepted this
message, 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 foreign agent MUST silently
discard the Notification Acknowledgement message. If the foreign
agent accepted this message, the home agent MAY also process it based
on the notification event.
If the "MD" value is set to 3, and the foreign agent accepted 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,
Deng, et al. Expires August 15, 2008 [Page 16]
Internet-Draft MIP4 Generic Notification Message February 2008
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
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
Deng, et al. Expires August 15, 2008 [Page 17]
Internet-Draft MIP4 Generic Notification Message February 2008
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].
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, otherwise it came from
the foreign agent.
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, and the home agent accepted this
message, the Mobile-Home Authentication extension MUST be checked,
and the home agent MUST check the Authenticator value in the
Extension. If no Mobile-Home Authentication Extension is found, or
if more than one Mobile-Home Authentication Extension is found, or if
the Authenticator is invalid, the home agent MUST silently discard
Deng, et al. Expires August 15, 2008 [Page 18]
Internet-Draft MIP4 Generic Notification Message February 2008
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, 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 message. If home agent accepts the foreign agent's
generic notification message, it will process it based on the
notification extension. Furthermore, the home agent MAY reply with a
Generic Notification Acknowledgement message back to the foreign
agent based on the "A" flag in the notification message.
4.5.4. Sending Generic Notification Acknowledgement Messages
If the generic notification message came from the foreign agent only,
the home agent MAY reply with a generic notification acknowledgement
message to the foreign agent based on the "A" flag in the
notification message. If the "A" flag is set in the notification
message, then the home agent MUST send a Notification Acknowledgement
message. The message is as follows: The source address is home
agent's address, the destination address is the foreign agent's
address, the "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].
Deng, et al. Expires August 15, 2008 [Page 19]
Internet-Draft MIP4 Generic Notification Message February 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
[RFC3344]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.
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 August 15, 2008 [Page 20]
Internet-Draft MIP4 Generic Notification Message February 2008
6. Security Considerations
This specification operates in the security constraints and
requirements of [RFC3344]. 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 for the Generic Notification message
is used to provide replay protection for the notification messages
initiated by the Foreign Agent.
Deng, et al. Expires August 15, 2008 [Page 21]
Internet-Draft MIP4 Generic Notification Message February 2008
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]. The subtype of these two
messages indicate what kind of information is carried and will be
under assigned by IANA namespace.
Deng, et al. Expires August 15, 2008 [Page 22]
Internet-Draft MIP4 Generic Notification Message February 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 August 15, 2008 [Page 23]
Internet-Draft MIP4 Generic Notification Message February 2008
Authors' Addresses
Hui Deng
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: denghui@chinamobile.com
Henrik Levkowetz
Ericsson Research
Torshamsgatan 23
S-164 80, Stockholm
SWEDEN
Email: henrik@levkowetz.com
Vijay Devarapalli
Azaire Networks
4800 Great America Pkwy
Santa Clara, CA 95054
USA
Email: vijay.devarapalli@azairenet.com
Sri Gundavelli
Cisco Systems
170 W.Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Brian Haley
Hewlett-Packard Company
110 Spitbrook Road
Nashua, NH 03062
USA
Email: brian.haley@hp.com
Deng, et al. Expires August 15, 2008 [Page 24]
Internet-Draft MIP4 Generic Notification Message February 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Deng, et al. Expires August 15, 2008 [Page 25]