draft-ietf-mip4-generic-notification-message-11.txt   draft-ietf-mip4-generic-notification-message-14.txt 
MIP4 Working Group H. Deng MIP4 Working Group H. Deng
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Standards Track H. Levkowetz Intended status: Standards Track H. Levkowetz
Expires: March 12, 2010 Ericsson Research Expires: September 9, 2010 Ericsson Research
V. Devarapalli V. Devarapalli
WiChorus WiChorus
S. Gundavelli S. Gundavelli
Cisco Systems Cisco Systems
B. Haley B. Haley
Hewlett-Packard Company Hewlett-Packard Company
September 8, 2009 March 8, 2010
Generic Notification Message for Mobile IPv4 Generic Notification Message for Mobile IPv4
draft-ietf-mip4-generic-notification-message-11.txt draft-ietf-mip4-generic-notification-message-14.txt
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 12, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document specifies protocol enhancements that allow Mobile IPv4 described in the BSD License.
entities to send and receive explicit notification messages using a
new Mobile IPv4 message type designed for this purpose.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Notification message - Usage Scenario's . . . . . . . . . . . 7 3. Notification message - Usage Scenario's . . . . . . . . . . . 6
3.1. Notification message between a Home Agent and a Mobile 3.1. Notification message between a Home Agent and a Mobile
Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Mobile Registered using a Foreign Agent Care-of 3.1.1. Mobile Registered using a Foreign Agent Care-of
Address . . . . . . . . . . . . . . . . . . . . . . . 7 Address . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Mobile Registered using a Co-located Care-of 3.1.2. Mobile Registered using a Co-located Care-of
Address . . . . . . . . . . . . . . . . . . . . . . . 7 Address . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Notification message between a Foreign Agent and a 3.2. Notification message between a Foreign Agent and a
Mobile Node . . . . . . . . . . . . . . . . . . . . . . . 7 Mobile Node . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Notification message between a Home Agent and a 3.3. Notification message between a Home Agent and a
Foreign Agent . . . . . . . . . . . . . . . . . . . . . . 8 Foreign Agent . . . . . . . . . . . . . . . . . . . . . . 7
4. Generic Notification Message and Considerations . . . . . . . 9 4. Generic Notification Message and Considerations . . . . . . . 8
4.1. Generic Notification Message . . . . . . . . . . . . . . . 9 4.1. Generic Notification Message . . . . . . . . . . . . . . . 8
4.2. Generic Notification Acknowledgment Message . . . . . . . 12 4.2. Generic Notification Acknowledgment Message . . . . . . . 11
4.3. Notification Retransmision . . . . . . . . . . . . . . . . 16 4.3. Notification Retransmision . . . . . . . . . . . . . . . . 14
4.4. Mobile Node Consideration . . . . . . . . . . . . . . . . 16 4.4. Mobile Node Consideration . . . . . . . . . . . . . . . . 14
4.4.1. Receiving Generic Notification Messages . . . . . . . 16 4.4.1. Receiving Generic Notification Messages . . . . . . . 15
4.4.2. Sending Generic Notification Acknowledgement 4.4.2. Sending Generic Notification Acknowledgement
Message . . . . . . . . . . . . . . . . . . . . . . . 17 Message . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.3. Sending Generic Notification Messages . . . . . . . . 18 4.4.3. Sending Generic Notification Messages . . . . . . . . 16
4.4.4. Receiving Generic Notification Acknowledgement 4.4.4. Receiving Generic Notification Acknowledgement
Messages . . . . . . . . . . . . . . . . . . . . . . . 19 Messages . . . . . . . . . . . . . . . . . . . . . . . 17
4.5. Foreign Agent Consideration . . . . . . . . . . . . . . . 19 4.5. Foreign Agent Consideration . . . . . . . . . . . . . . . 18
4.5.1. Receiving Generic Notification Message . . . . . . . . 20 4.5.1. Receiving Generic Notification Message . . . . . . . . 18
4.5.2. Sending Generic Notification Acknowledgement 4.5.2. Sending Generic Notification Acknowledgement
Messages . . . . . . . . . . . . . . . . . . . . . . . 21 Messages . . . . . . . . . . . . . . . . . . . . . . . 20
4.5.3. Sending Generic Notification Messages . . . . . . . . 22 4.5.3. Sending Generic Notification Messages . . . . . . . . 20
4.5.4. Receiving Generic Notification Acknowledgement 4.5.4. Receiving Generic Notification Acknowledgement
Messages . . . . . . . . . . . . . . . . . . . . . . . 23 Messages . . . . . . . . . . . . . . . . . . . . . . . 21
4.6. Home Agent Consideration . . . . . . . . . . . . . . . . . 24 4.6. Home Agent Consideration . . . . . . . . . . . . . . . . . 22
4.6.1. Sending Generic Notification Messages . . . . . . . . 24 4.6.1. Sending Generic Notification Messages . . . . . . . . 22
4.6.2. Receiving Generic Notification Acknowledgement 4.6.2. Receiving Generic Notification Acknowledgement
Messages . . . . . . . . . . . . . . . . . . . . . . . 24 Messages . . . . . . . . . . . . . . . . . . . . . . . 23
4.6.3. Receiving Generic Notification Messages . . . . . . . 25 4.6.3. Receiving Generic Notification Messages . . . . . . . 23
4.6.4. Sending Generic Notification Acknowledgement 4.6.4. Sending Generic Notification Acknowledgement
Messages . . . . . . . . . . . . . . . . . . . . . . . 26 Messages . . . . . . . . . . . . . . . . . . . . . . . 24
5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 28 5. Future Extensibility . . . . . . . . . . . . . . . . . . . . . 26
5.1. Generic String Extension . . . . . . . . . . . . . . . . . 28 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 7.1. Replay Protection for GNM, GNAM messages . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7.1.1. Replay Protection using Timestamps . . . . . . . . . . 29
8.1. Replay Protection for GNM, GNAM messages . . . . . . . . . 31 7.1.2. Replay Protection using Nonces . . . . . . . . . . . . 30
8.1.1. Replay Protection using Timestamps . . . . . . . . . . 32 7.2. Non-authentication Extensions Handling in Foreign Agent . 30
8.1.2. Replay Protection using Nonces . . . . . . . . . . . . 33 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
8.2. Non-authentication Extensions Handling in Foreign Agent . 33 9. Normative References . . . . . . . . . . . . . . . . . . . . . 32
9. Normative References . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
In some situations, there is a need for Mobile IPv4 entities, such as In some situations, there is a need for Mobile IPv4 entities, such as
the home agent(HA), foreign agent(FA) and mobile node(MN) to send and the home agent(HA), foreign agent(FA) and mobile node(MN) to send and
receive asynchronous notification messages during a mobility session. receive asynchronous notification messages during a mobility session.
The base Mobile IP Specification [RFC3344] does not have a provision The base Mobile IP Specification [RFC3344] does not have a provision
for this. for this.
This document defines a generic message and a notification model that This document defines a generic message and a notification model that
can be used by Mobile IPv4 entities to send various notifications. can be used by Mobile IPv4 entities to send various notifications.
However, this specification does not define any specific notification It also defines a corresponding acknowledgement message to allow for
message or the actions that the receiving entity is required to reliable delivery of notifications. The messages defined in this
perform on receiving that message. Specific extensions and the document are capable of carrying the same extensions that have been
corresponding handler actions are outside the scope of this document. defined for the existing Mobile IPv4 messages. However, this
document requires for now that only the following extensions be
present in the new messages defined herein:
- MN-HA Authentication Extension
- MN-FA Authentication Extension
- FA-HA Authentication Extension
- Generic String Extension
For now, the semantics of receiving a generic notification message
are null; i.e., it has no effect on the state of a mobile node's
existing registration. See Section 5 for some prospective
application examples that motivate the new messages defined in this
document. Future documents may specify additional extension types
that may be used in a generic notification message and their
semantics.
2. Terminology 2. Terminology
It is assumed that the reader is familiar with the terminology used It is assumed that the reader is familiar with the terminology used
in [RFC4917], [RFC3344]. In addition, the following terms are in [RFC4917], [RFC3344]. In addition, the following terms are
defined: defined:
Notification Message Notification Message
A message from a mobility agent to a MN or other mobility agent to A message from a mobility agent to a MN or other mobility agent to
skipping to change at page 9, line 31 skipping to change at page 9, line 31
- the UDP destination port of the Registration Request/Reply - the UDP destination port of the Registration Request/Reply
The sending node always sends the GNM message following the same The sending node always sends the GNM message following the same
procedure for sending Registration Request as in section 3.3 of procedure for sending Registration Request as in section 3.3 of
[RFC3344] and the receiving node follows the same procedure for [RFC3344] and the receiving node follows the same procedure for
Registration Reply as in section 3.4. of [RFC3344] when sending GNAM. Registration Reply as in section 3.4. of [RFC3344] when sending GNAM.
4.1. Generic Notification Message 4.1. Generic Notification Message
A GNM is sent by a mobility agent to inform another mobility agent, A GNM is sent by a mobility agent to inform another mobility agent,
or a MN, of MIP-related information such as vendor specific or a MN, of MIP-related information such as generic string
extensions[RFC3115] and generic string notification[RFC4917]. These notification[RFC4917]. These messages MUST use the same IP and UDP
messages MUST use the same IP and UDP headers as any previous headers as any previous Registration Request(RRQ) or Reply (RRP)
Registration Request(RRQ) or Reply (RRP) message to the same entity. message to the same entity. This would support NAT traversal and
This would support NAT traversal and ensure same security association ensure same security association used for GNM/GNAM and RRQ/RRP. The
used for GNM/GNAM and RRQ/RRP. The GNM is defined as follows: GNM is defined as follows:
IP Fields: IP Fields:
Source Address Copied from the source address field of the Source Address Typically copied from the destination
last Registration Reply/Request message address of the last Registration Reply/
sent. Request message that the agent received from
the agent to which it is sending the GNM.
Destination Address Copied from the source address field of the Destination Address Copied from the source address of the last
last Registration Reply/Request message Registration Reply/Request message that the
sent. agent received from the agent to which it is
sending the GNM.
UDP Fields: UDP Fields:
Source Port Copied from the source address field of the Source Port Typically copied from the destination port
last Registration Reply/Request message of the last Registration Reply/Request
sent. message that the agent received from the
agent to which it is sending the GNM.
Destination Port Copied from the source address field of the Destination Port Copied from the source port of the last
last Registration Reply/Request message Registration Reply/Request message that the
sent. agent received from the agent to which it is
sending the GNM.
The UDP header is followed by the Mobile IP fields shown below: The UDP header is followed by the Mobile IP fields shown below:
0 1 2 3 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 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 | | Type | MD |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address | | Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address | | Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address | | Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Identification + + Identification +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions... | Extensions...
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-
Type (To be assigned by IANA) Type (To be assigned by IANA)
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 which is
specified in [RFC3115].
2 Information carried in Generic String extensions which is
specified in [RFC4917].
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 MD: Message Direction
This memo defines the semantics of the following MD field value: This memo defines the semantics of the following MD field value:
0 -- Message sent by the HA to the MN 0 -- Message sent by the HA to the MN
1 -- Message sent by the HA to the FA 1 -- Message sent by the HA to the FA
2 -- Message sent by the MN to the HA 2 -- Message sent by the MN to the HA
skipping to change at page 13, line 8 skipping to change at page 12, line 37
corresponding GNM. corresponding GNM.
Destination Port Copied from the source port of the Destination Port Copied from the source port of the
corresponding GNM. corresponding GNM.
The UDP header is followed by the Mobile IP fields shown below: The UDP header is followed by the Mobile IP fields shown below:
0 1 2 3 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 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 | code | | Type | MD | code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address | | Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address | | Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address | | Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Identification + + Identification +
| | | |
skipping to change at page 13, line 22 skipping to change at page 13, line 4
| Home Agent Address | | Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address | | Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Identification + + Identification +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions... | Extensions...
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-
Type (To be assgined by IANA) Type (To be assgined by IANA)
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 which is
specified in [RFC3115].
2 Information carried in Generic String extensions which is
specified in [RFC4917].
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 MD: Message Direction
This memo defines the semantics of the following MD field value: This memo defines the semantics of the following MD field value:
0 -- Message sent by the HA to the MN 0 -- Message sent by the HA to the MN
1 -- Message sent by the HA to the FA 1 -- Message sent by the HA to the FA
2 -- Message sent by the MN to the HA 2 -- Message sent by the MN to the HA
3 -- Message sent by the MN to the FA 3 -- Message sent by the MN to the FA
4 -- Message sent by the FA to the MN 4 -- Message sent by the FA to the MN
5 -- Message sent by the FA to the HA 5 -- Message sent by the FA to the HA
code code
skipping to change at page 28, line 5 skipping to change at page 27, line 5
If the GNM message came from the MN, and if the "A" flag is set in If the GNM message came from the MN, and if the "A" flag is set in
the GNM message, then the HA MUST send a GNAM message. The message the GNM message, then the HA MUST send a GNAM message. The message
is as follows: The source address is HA's address, the destination is as follows: The source address is HA's address, the destination
address is the FA's address, the "MD" value is set to 0. The address is the FA's address, the "MD" value is set to 0. The
ordering of the extension is: any non-authentication Extensions used ordering of the extension is: any non-authentication Extensions used
only by the MN, followed by the MN-HA AE defined in section 3.5.2. of only by the MN, followed by the MN-HA AE defined in section 3.5.2. of
[RFC3344], optionly followed by any non-authentication Extensions [RFC3344], optionly followed by any non-authentication Extensions
used only by the FA, optionly followed by The MN-FA AE defined in used only by the FA, optionly followed by The MN-FA AE defined in
section 3.5.3 of [RFC3344] section 3.5.3 of [RFC3344]
5. Usage Example 5. Future Extensibility
The HA, FA, and MN SHOULD expose a list of the supported
notifications to operators via some management interface, and there
SHOULD be switches to enable / disable individual types of
notifications and controllers to tune the retransmission timers for
each type.
There are several applications that could use this GNM. For example, There are several applications that could use this GNM. For example,
during handover between CDMA 2000 1x EV-DO and Wireless LAN, the PPP during handover between CDMA 2000 1x EV-DO and Wireless LAN, the PPP
resource of CDMA side have to be removed on the FA (PDSN) to avoid resource on the CDMA side has to be removed on the FA (PDSN) to avoid
over-charging subscribers. Other applications such as HA switch over-charging subscribers, anyway existing Registration Revocation
over, NEMO prefix changes, service or billing related events, load RFC [RFC3543] is a one way to do this. Other applications such as HA
balancing where the HA wants to move some of the registered mobile switch over(before HA decide to go offline it would like to notify
nodes to other HAs, service termination due to end of prepaid time, the MNs to register with another candidate HA), NEMO prefix
and service interruption due to system maintenance. changes(MN is notified by HA about NEMO prefix changes and service or
billing related events, which is an operational requirement), Load
balancing(HA wants to move some of the registered MNs to other HAs),
Service Termination(due to end of prepaid time), and Service
Interruption(due to system maintenance).
Here we describe some possible event which could use the generic This document describes how to use Generic String Extension [RFC4917]
string extension [RFC4917] based on this notification mechanism. based on this notification mechanism.
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. Generic String Extension In some case, the HA or FA needs to notify the MN 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 easily recognized by the MN. An
example would be "Maintenance Downtime", "Prepaid Expiration". On
the other hand, the MN may need to notify the network about events
related to a service such as a location change event, or a usage-
preference change event. This information could be defined based on
a string [RFC4917]. An example would be "Location Change" or
"Service Event". These strings MUST be strictly defined so they
could be easily understood by all of the network entities, and a
suitable GNM Subtype number would have to be allocated. All such
definitions are left for future specifications.
In some case, the HA or FA needs to notify the mobile node about For now, none of these above future semantics are supported except
service termination due to the end of prepaid time, or service that the Generic String Extension is supported for informational
interruption due to system maintenance. This information could be purposes. There should be minimum requirements given here for adding
defined based on a string [RFC4917] which is recognized by the MN additional extension types to the allowed set and defining their
easily. An example would be "Maintenance Downtime", "Prepaid semantics.
Expiration". These string MUST be strictly defined so they could be
easily understood by all of the network entities, and a suitable GNM
Subtype number would have to be allocated. All such definitions are
left for future specifications.
6. IANA Considerations 6. IANA Considerations
This document describes two new messages, the GNM in section 4.1 and This document describes two new messages, the GNM in section 4.1 and
the GNAM in section 4.2. These two messages SHOULD be allocated from the GNAM in section 4.2. These two messages SHOULD be allocated from
the same address space used by the Registration Request and the same address space used by the Registration Request and
Registration Reply messages in [RFC3344]. The subtype of these two Registration Reply messages in [RFC3344]. The subtype of these two
messages indicate what kind of information is carried and will be messages indicate the information that GNM is carrying, and it will
under assigned by IANA namespace. be under assigned by IANA namespace.
This document creates a new IANA registry for the Subtype field in
the GNM and GNAM. New values MUST be allocated by Standards Actions
or IETF Consensus. This document reserves three values for the
Subtype field
0 Reserved
1 Information carried in Vendor specific extensions
2 Information carried in Generic String Extension
This GNAM message, specified in section section 4.2, has a Code This GNAM message, specified in section section 4.2, has a Code
field. The number space for the Code field values is also specified field. The number space for the Code field values is also specified
in section 4.2. The Code number space is strucutred according to in section 4.2. The Code number space is strucutred according to
whether the notification was successful, or whether the HA denied the whether the notification was successful, or whether the HA denied the
notification, or whether FA denied the notification, or whether MN notification, or whether FA denied the notification, or whether MN
denied the notification, as follows denied the notification, as follows
0 Success Code 0 Success Code
64-69 Error Codes from the FA 64-69 Error Codes from the FA
128-133 Error Codes from the HA 128-133 Error Codes from the HA
192-197 Error Codes from the MN 192-197 Error Codes from the MN
Approval of new Code values require expert review. Approval of new Code values require expert review.
7. Acknowledgments 7. Security Considerations
The author appreciate the efforts of Ahmad Muhanna for his detail
reviewing of this document and his many contributions to the text of
this document. The author also wants to thank Kent Leung, Peng Yang
and Peter McCann et al. for their helping developing this document.
Thanks to Alexey Melnikov, Sean Turner, Charles E. Perkins, and
Joseph Salowey's discussion and comments. Thanks to Jari Arkko for
each step of this document.
8. Security Considerations
This specification operates in the security constraints and This specification operates in the security constraints and
requirements of [RFC3344]. It require that when these message is requirements of [RFC3344]. It require that when these message is
transmitted between the MN and the HA, MN-HA AE is mandatory, when transmitted between the MN and the HA, MN-HA AE is mandatory, when
this message is transmitted between the MN and the FA, MN-FA AE is this message is transmitted between the MN and the FA, MN-FA AE is
mandatory, when this message is transmitted between the FA and the mandatory, when this message is transmitted between the FA and the
HA, FA-HA AE is mandatory. It extends the operations of MN, HA and HA, FA-HA AE is mandatory. It extends the operations of MN, HA and
FA defined in [RFC3344] to notify each other about some events. The FA defined in [RFC3344] to notify each other about some events. The
GNM message defined in the specification could carry information that GNM message defined in the specification could carry information that
modifies the mobility bindings. Therefore the message MUST be modifies the mobility bindings. Therefore the message MUST be
integrity protected. Replay protection MUST also be guaranteed. integrity protected. Replay protection MUST also be guaranteed.
RFC 3344 provides replay protection only for registration requests RFC 3344 provides replay protection only for registration requests
sent by the MN. There is no mechanism for replay protection for sent by the MN. There is no mechanism for replay protection for
messages initiated by a FA or a HA. The 64-bit Identification field messages initiated by a FA or a HA. The 64-bit Identification field
specified in this document (Section 4.1 and 4.2) for the GNM message specified in this document (Section 4.1 and 4.2) for the GNM message
is used to provide replay protection for the notification messages is used to provide replay protection for the notification messages
initiated by the FA or HA. initiated by the FA or HA.
8.1. Replay Protection for GNM, GNAM messages 7.1. Replay Protection for GNM, GNAM messages
The Identification field is used to let the receiving node verify The Identification field is used to let the receiving node verify
that a GNM has been freshly generated by the sending node, not that a GNM has been freshly generated by the sending node, not
replayed by an attacker from some previous registration. Two methods replayed by an attacker from some previous registration. Two methods
are described in this section: timestamps (mandatory) and "nonces" are described in this section: timestamps (mandatory) and "nonces"
(optional). All senders and receivers MUST implement timestamp-based (optional). All senders and receivers MUST implement timestamp-based
replay protection. These nodes MAY also implement nonce-based replay replay protection. These nodes MAY also implement nonce-based replay
protection protection
The style of replay protection in effect between any two peer nodes The style of replay protection in effect between any two peer nodes
among MN, FA and HA. A sending node and its receiving node MUST among MN, FA and HA is part of the mobile security association. A
agree on which method of replay protection will be used. The sending node and its receiving node MUST agree on which method of
interpretation of the Identification field depends on the method of replay protection will be used. The interpretation of the
replay protection as described in the subsequent subsections. Identification field depends on the method of replay protection as
described in the subsequent subsections.
Whatever method is used, the low-order 32 bits of the Identification Whatever method is used, the low-order 32 bits of the Identification
MUST be copied unchanged from the GNM to the GNMA. The receiver uses MUST be copied unchanged from the GNM to the GNMA. The receiver uses
those bits (and the sender's source address) to match GNAM with those bits (and the sender's source address) to match GNAM with
corresponding replies. The receiver MUST verify that the low-order corresponding replies. The receiver MUST verify that the low-order
32 bits of any GNAM are identical to the bits it sent in the GNM. 32 bits of any GNAM are identical to the bits it sent in the GNM.
The Identification in a new GNM MUST NOT be the same as in an The Identification in a new GNM MUST NOT be the same as in an
immediately preceding GNM, and SHOULD NOT repeat while the same immediately preceding GNM, and SHOULD NOT repeat while the same
security context is being used between the MN and the HA. security context is being used between the MN and the HA.
8.1.1. Replay Protection using Timestamps 7.1.1. Replay Protection using Timestamps
The basic principle of timestamp replay protection is that the node The basic principle of timestamp replay protection is that the node
generating a message inserts the current time of day, and the node generating a message inserts the current time of day, and the node
receiving the message checks that this timestamp is sufficiently receiving the message checks that this timestamp is sufficiently
close to its own time of day. Unless specified differently in the close to its own time of day. Unless specified differently in the
security association between the nodes, a default value of 7 seconds security association between the nodes, a default value of 7 seconds
MAY be used to limit the time difference. This value SHOULD be MAY be used to limit the time difference. This value SHOULD be
greater than 3 seconds. Obviously the two nodes must have adequately greater than 3 seconds. Obviously the two nodes must have adequately
synchronized time-of-day clocks. As with any messages, time synchronized time-of-day clocks. As with any messages, time
synchronization messages may be protected against tampering by an synchronization messages may be protected against tampering by an
skipping to change at page 33, line 5 skipping to change at page 31, line 5
low-order 32 bits into the GNAM, and supplies the high-order 32 bits low-order 32 bits into the GNAM, and supplies the high-order 32 bits
from its own time of day. In this latter case, the receiver MUST from its own time of day. In this latter case, the receiver MUST
reject the registration by returning Code 69/133/197 (identification reject the registration by returning Code 69/133/197 (identification
mismatch) in the GNAM message. mismatch) in the GNAM message.
Furthermore, the receiver MUST verify that the low-order 32 bits of Furthermore, the receiver MUST verify that the low-order 32 bits of
the Identification in the GNAM are identical to those in the rejected the Identification in the GNAM are identical to those in the rejected
GNM attempt, before using the high-order bits for clock GNM attempt, before using the high-order bits for clock
resynchronization. resynchronization.
8.1.2. Replay Protection using Nonces 7.1.2. Replay Protection using Nonces
The basic principle of nonce replay protection is that node A The basic principle of nonce replay protection is that node A
includes a new random number in every message to node B, and checks includes a new random number in every message to node B, and checks
that node B returns that same number in its next message to node A. that node B returns that same number in its next message to node A.
Both messages use an authentication code to protect against Both messages use an authentication code to protect against
alteration by an attacker. At the same time node B can send its own alteration by an attacker. At the same time node B can send its own
nonces in all messages to node A (to be echoed by node A), so that it nonces in all messages to node A (to be echoed by node A), so that it
too can verify that it is receiving fresh messages. too can verify that it is receiving fresh messages.
The receiver may be expected to have resources for computing pseudo- The receiver may be expected to have resources for computing pseudo-
skipping to change at page 33, line 40 skipping to change at page 31, line 40
node that checks for valid values in the GNAM message. The high- node that checks for valid values in the GNAM message. The high-
order and low-order 32 bits of the identification chosen SHOULD both order and low-order 32 bits of the identification chosen SHOULD both
differ from their previous values. The receiver uses a new high- differ from their previous values. The receiver uses a new high-
order value and the sender uses a new low-order value for each order value and the sender uses a new low-order value for each
registration message. registration message.
If a GNM message is rejected because of an invalid nonce, the GNAM If a GNM message is rejected because of an invalid nonce, the GNAM
always provides the sender with a new nonce to be used in the next always provides the sender with a new nonce to be used in the next
registration. Thus the nonce protocol is self- synchronizing. registration. Thus the nonce protocol is self- synchronizing.
8.2. Non-authentication Extensions Handling in Foreign Agent 7.2. Non-authentication Extensions Handling in Foreign Agent
When the FA is relaying the GNM message between the MN and the HA, When the FA is relaying the GNM message between the MN and the HA,
and if the FA does not share a mobility security association with the and if the FA does not share a mobility security association with the
MN or HA, all non-authentication extensions between MN and FA, or FA MN or HA, all non-authentication extensions between MN and FA, or FA
and HA are not protected; In this case, all non-authentication and HA are not protected; In this case, all non-authentication
extensions should be silently discarded. extensions should be silently discarded.
8. Acknowledgments
The author appreciate the efforts of Ahmad Muhanna for his detail
reviewing of this document and his many contributions to the text of
this document. The author also wants to thank Kent Leung, Peng Yang
and Peter McCann et al. for their helping developing this document.
Thanks to Alexey Melnikov, Sean Turner, Ralph Droms, Charles E.
Perkins, Russ Housley, Magnus Westerlund, Lars Eggert, Dan Romascanu,
Tim Polk, Amanda Baber, Sebastian Thalanany, and Joseph Salowey's
discussion and comments. Thanks to Jari Arkko for each step of this
document.
9. Normative References 9. Normative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/ [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/
Organization-Specific Extensions", RFC 3115, April 2001. Organization-Specific Extensions", RFC 3115, April 2001.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. 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 [RFC4917] Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message
String Extension", RFC 4917, June 2007. String Extension", RFC 4917, June 2007.
Authors' Addresses Authors' Addresses
Hui Deng Hui Deng
China Mobile China Mobile
53A,Xibianmennei Ave., 53A,Xibianmennei Ave.,
Xuanwu District, Xuanwu District,
Beijing 100053 Beijing 100053
 End of changes. 45 change blocks. 
181 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/