[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

   MIP6 Working Group                                       Brian Haley
   Internet Draft                                       Hewlett-Packard
   Intended status: Standards Track                      Sri Gundavelli
   Expires: January, 2008                                 Cisco Systems
                                                           October 2007



               Generic Notification Message for Mobile IPv6
            draft-ietf-mip6-generic-notification-message-00.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html


Abstract

   This document specifies a new Mobility Header message type that
   allows Mobile IPv6 entities to send and receive generic notification
   messages.


Conventions used in this document

   The key words "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 [1].




Haley                   Expires - January 2008                [Page 1]


             Generic Notification Message for Mobile IPv6 October 2007


Table of Contents

   1. Introduction...................................................2
   2. Generic Notification Messages..................................2
      2.1 Generic Notification Request Message.......................3
      2.2 Generic Notification Acknowledgement Message...............4
   3. Sending Generic Notification Messages..........................5
      3.1 Sending Generic Notification Request Messages..............5
      3.2 Sending Generic Notification Acknowledgement Messages......6
   4. Receiving Generic Notification Messages........................6
      4.1 Receiving Generic Notification Request Messages............6
      4.1.1 Mobile Node Operation....................................7
      4.1.2 Home Agent Operation.....................................7
      4.1.3 Retransmissions..........................................7
   5. Protocol Constants.............................................8
   6. IANA Considerations............................................8
   7. Security Considerations........................................8
   8. References.....................................................8
      8.1 Normative Reference........................................8
      8.2 Informative references.....................................9
   Acknowledgments...................................................9
   Author's Addresses................................................9


1. Introduction

   RFC 3775 [2] contains no provision for Mobile IPv6 entities, such as
   a home agent or mobile node, to send and receive asynchronous
   notification messages during a mobility session.

   This document describes a generic notification message protocol that
   can be used by Mobile IPv6 entities for sending and receiving simple
   notification events.

   The document does not define any specific events, or the
   corresponding actions that the receiver is required to do upon
   receiving an event.

2. Generic Notification Messages

   The messages described below follow the Mobility Header format
   specified in Section 6.1 of [2]:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Payload Proto |  Header Len   |   MH Type     |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Checksum            |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |


Haley                   Expires - January 2008                [Page 2]


             Generic Notification Message for Mobile IPv6 October 2007


    |                                                               |
    .                                                               .
    .                       Message Data                            .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1 Generic Notification Request Message

   The Generic Notification Request message is used by the home agent to
   notify the mobile node, or vice-versa, that there is an event that
   requires attention.  This packet is sent as described in Section 3.

   The Generic Notification Request message uses the MH Type value
   (TBD).  When this value is indicated in the MH Type field, the format
   of the Message Data field in the Mobility Header is as follows:

    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |A|  Reserved   |   Sequence #  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Mobility options                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Acknowledge (A)

     The Acknowledge (A) bit is set by the sender to request a Generic
     Notification Acknowledgement (Section 3.1) be returned upon receipt
     of a Generic Notification Request.

   Reserved

     These fields are unused.  They MUST be initialized to zero by the
     sender, and MUST be ignored by the receiver.

   Sequence #

     An 8-bit unsigned integer used by the receiving node to sequence
     Generic Notification Requests and by the sending node to match a
     returned Generic Notification Acknowledgement with this Generic
     Notification Request.



Haley                   Expires - January 2008                [Page 3]


             Generic Notification Message for Mobile IPv6 October 2007


   Mobility options

     Variable-length field of such length that the complete Mobility
     Header is an integer multiple of 8 octets long.  This field
     contains zero of more TLV-encoded mobility options.  The encoding
     and format of defined options MUST follow the format specified in
     Section 6.2 of [2].  The receiver MUST ignore and skip any options
     with it does not understand.

     This specification does not define any options valid for the
     Generic Notification Request message.

   If no options are present in this message, no padding is necessary
   and the Header Len field in the Mobility Header will be set to 0.

2.2 Generic Notification Acknowledgement Message

   The Generic Notification Acknowledgement message is used by the home
   agent to notify the mobile node, or vice-versa, that there is an
   event that requires attention.  This packet is sent as described in
   Section 3.

   The Generic Notification Acknowledgement message uses the MH Type
   value (TBD).  When this value is indicated in the MH Type field, the
   format of the Message Data field in the Mobility Header is as
   follows:

    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |    Status     |   Sequence #  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Mobility options                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Status

     8-bit unsigned integer indicating the disposition of the Signaling
     Request.  Values of the Status field less than 128 indicate that
     the Signaling Request was accepted by the receiving node.  Values
     greater than or equal to 128 indicate that the Signaling Request
     was rejected by the receiving node.  The following Status values
     are currently defined:



Haley                   Expires - January 2008                [Page 4]


             Generic Notification Message for Mobile IPv6 October 2007


          0 Notification Request accepted

        128 Reason unspecified

        129 Administratively prohibited

        130 Insufficient resources

        131 Unsupported mobility option

        132 Not home agent for this mobile node

   Sequence #

     An 8-bit unsigned integer used by the receiving node to sequence
     Generic Notification Requests and by the sending node to match a
     returned Generic Notification Acknowledgement with this Generic
     Notification Request.  The sequence number in the Generic
     Notification Acknowledgement is copied from the sequence number
     field in the Generic Notification Request.

   Mobility options

     Variable-length field of such length that the complete Mobility
     Header is an integer multiple of 8 octets long.  This field
     contains zero of more TLV-encoded mobility options.  The encoding
     and format of defined options MUST follow the format specified in
     Section 6.2 of [2].  The receiver MUST ignore and skip any options
     with it does not understand.

     This specification does not define any options valid for the
     Generic Notification Acknowledgement message.

   If no options are present in this message, no padding is necessary
   and the Header Len field in the Mobility Header will be set to 0.

3. Sending Generic Notification Messages

3.1 Sending Generic Notification Request Messages

   When sending a Generic Notification message, the sending node
   constructs the packet as it would any other Mobility Header, except:

     o The MH Type field MUST be set to (TBD).
     o The Acknowledge (A) bit MAY be set to indicate the receiver must
        send a Generic Notification Acknowledgement.

   The Generic Notification Request message MUST use the home agent to
   mobile node IPsec ESP authentication SA for integrity protection.


Haley                   Expires - January 2008                [Page 5]


             Generic Notification Message for Mobile IPv6 October 2007



3.2 Sending Generic Notification Acknowledgement Messages

   A Generic Notification Acknowledgement message should be sent to
   indicate receipt of a Generic Notification Request as follows:

     o If the Generic Notification Request was discarded because it
        does not meet the requirements as specified in [2] described in
        Section 4, a Generic Notification Acknowledgement MUST NOT be
        sent.  Otherwise, the treatment depends on the below rule.

     o If the Acknowledgement (A) bit is set in the Generic
        Notification Request, a Generic Notification Acknowledgement
        MUST be sent.  Otherwise, the treatment depends on the below
        rule.

     o If the Generic Notification Request was discarded for any other
        reason, a Generic Notification Acknowledgement SHOULD be sent.

   If the Source Address field of the IPv6 header that carried the
   Generic Notification Request does not contain a unicast address, the
   Generic Notification Acknowledgement MUST NOT be sent, and the
   Generic Notification Request packet MUST be silently discarded.
   Otherwise, the acknowledgement MUST be sent to the Source Address.

4. Receiving Generic Notification Messages

   Upon receiving a Generic Notification message, the Mobility Header
   MUST be verified as specified in [2], specifically:

     o The Checksum, MH type, Payload Proto and Header Len fields MUST
        meet the requirements of Section 9.2 of [2].

     o The packet MUST be covered by the home agent to mobile node
        IPsec ESP authentication SA for integrity protection.

   If the packet is dropped due to the above tests, the receiving node
   MUST follow the processing rules as Section 9.2 of [2].  For example,
   it MUST send a Binding Error message with the Status field set to 2
   (unrecognized MH Type value) if it does not support the message type.

   Subsequent checks depend on the current mode of operation of the
   node.

4.1 Receiving Generic Notification Request Messages

   If the Generic Notification Request message is valid according to the
   tests in Section 4, then it is processed further as follows:



Haley                   Expires - January 2008                [Page 6]


             Generic Notification Message for Mobile IPv6 October 2007


     o If the receiving node does not allow Generic Notification
        Request messages, it MUST reject the request and SHOULD return a
        Generic Notification Acknowledgement to the sender in which the
        Status field is set to 129 (administratively prohibited).

     o If the receiving node does not support the type of Mobility
        Option in the Generic Notification Request message, it MUST
        reject the request and SHOULD return a Generic Notification
        Acknowledgement to the sender in which the Status field is set
        to 131 (unsupported mobility option).

   Subsequent checks depend on the current mode of operation of the
   node.

4.1.1 Mobile Node Operation

   If the mobile node rejects the Generic Notification Request message
   for any other reason than specified in Section 4, it SHOULD return a
   Generic Notification Acknowledgement to the home agent in which the
   Status field is set to 128 (reason unspecified).

4.1.2 Home Agent Operation

   If the receiving node is a home agent, it MUST perform these
   additional checks:

     o If the home agent has no entry marked as a home registration in
        its Binding Cache for this mobile node, then this node MUST
        reject the request and SHOULD return a Generic Notification
        Acknowledgement to the mobile node in which the Status field is
        set to 132 (not home agent for this mobile node).

     o If the home agent cannot process the Generic Notification
        Request message because it is over-utilized, it MUST reject the
        request and SHOULD return a Generic Notification Acknowledgement
        to the mobile node in which the Status field is set to 130
        (insufficient resources).

   If the home agent rejects the Generic Notification Request message
   for any other reason, it SHOULD return a Generic Notification
   Acknowledgement to the mobile node in which the Status field is set
   to 128 (reason unspecified).


4.1.3 Retransmissions





Haley                   Expires - January 2008                [Page 7]


             Generic Notification Message for Mobile IPv6 October 2007


   If the sender has set the Acknowledge (A) bit in the Generic
   Notification Request, but does not receive a Generic Notification
   Acknowledgement, then it MAY retransmit the message, until a response
   is received.  The initial value for the retransmission timer is
   INITIAL_MH_NOTIFICATION_TIMEOUT.  The retransmissions by the sender
   MUST use an exponential back-off mechanism, in which the timeout
   period is doubled upon each retransmission, until either the sender
   gets a response from the target node, or the timeout period reaches
   the value MAX_MH_NOTIFICATION_TIMEOUT.


5. Protocol Constants

   INITIAL_MH_NOTIFICATION_TIMEOUT        5 seconds
   MAX_MH_NOTIFICATION_TIMEOUT           20 seconds


6. IANA Considerations

   A new Mobility Header type is required for the following new message
   described in Section 2:

     (TBD) Generic Notification Request Message
     (TBD) Generic Notification Acknowledgement Message

7. Security Considerations

   As with other messages in [2], the Generic Notification message MUST
   use the home agent to mobile node ESP encryption SA for
   confidentiality protection, and MUST use the home agent to mobile
   node ESP authentication SA for integrity protection.

   The Generic Notification message MAY use the IPsec ESP SA in place
   for Binding Updates and Acknowledgements as specified in Section 5.1
   of [2], in order to reduce the number of configured security
   associations.  This also gives the message authenticity protection.


8. References

8.1 Normative Reference

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   [2]  Johnson, D. Perkins, C., and Arkko, J., "Mobility Support in
      IPv6", RFC 3775, June, 2004




Haley                   Expires - January 2008                [Page 8]


             Generic Notification Message for Mobile IPv6 October 2007



8.2 Informative references


Acknowledgments

   Thanks to Hui Deng, James Kempf and Vijay Devarapalli for their
   initial review of the draft.


Author's Addresses

   Brian Haley
   Hewlett-Packard Company
   110 Spitbrook Road
   Nashua, NH 03062, USA
   Email: brian.haley@hp.com

   Sri Gundavelli
   Cisco Systems
   170 W.Tasman Drive
   San Jose, CA 95134, USA
   Email: sgundave@cisco.com


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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


Haley                   Expires - January 2008                [Page 9]


             Generic Notification Message for Mobile IPv6 October 2007


   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.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).































Haley                   Expires - January 2008               [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/