[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
IETF Mobile IP Working Group                          Charles E. Perkins
INTERNET DRAFT                                     Nokia Research Center
15 April 2002                                             Francis Dupont
                                                           ENST Bretagne

                Nonfinal Mobility Header for Mobile IPv6
                    draft-ietf-mobileip-piggyback-00.txt


Status of This Memo

   This document is a submission by the IETF Mobile IP Working Group
   Working Group of the Internet Engineering Task Force (IETF).
   Comments should be submitted to the mobile-ip@sunroof.eng.sun.com
   mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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 operations to allow inclusion of data along
   with a mobility header (from Mobile IPv6) containing a Binding Update
   or Binding Acknowledgement message.  In this way, smoother handovers
   and reduced jitter and bandwidth utilization can be achieved.
   Interactions with IPsec-based verification of mobility messages are
   described; basically, establishment of such IPsec-based methods
   preclude the use of the mobility header specified in this document,
   unless simple modifications to IPsec (outside the scope of this
   document) can be utilized.









Perkins, Dupont            Expires 15 November 2002             [Page i]


Internet Draft          Nonfinal Mobility Header           15 April 2002




                                Contents


Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. Terminology                                                        2

 3. Nonfinal Mobility Message Header Format                            3

 4. Operation and Use of the Nonfinal Mobility Header                  3
     4.1. Rules for the Sender  . . . . . . . . . . . . . . . . . .    3
     4.2. Rules for the Correspondent Node  . . . . . . . . . . . .    3

 5. ICMP Payload Inclusion Control Message                             4

 6. IANA Considerations                                                4

 7. Security Considerations                                            5

 8. Acknowledgement                                                    5

References                                                             5

 A. Requesting Isolation of Payload and Mobility Headers               6

 B. Table of Nonfinal and Final Mobility Header vs IPsec-based
   Security                                                            7

 C. Mobility Signals Which May be Included with Payload                8

Addresses                                                              9


1. Introduction

   When a mobile node moves to a new point of attachment, it can use
   a Mobile IPv6 Binding Update message [3] to supply a new care-of
   address to a correspondent node.  This information can conveniently
   be located in the same packet as data which the mobile node may be
   already transmitting towards the correspondent node.  In this way,
   smoother handovers and reduced jitter and bandwidth utiliziation can
   be achieved.




Perkins, Dupont            Expires 15 November 2002             [Page 1]


Internet Draft          Nonfinal Mobility Header           15 April 2002


   Such operation has been described in Mobile IPv6 specifications until
   recently, when concerns about IPsec policy ambiguity led to a more
   restrictive approach towards verifying the authentication data in
   the Mobility Header.  Basically, establishment of such IPsec-based
   security associations for verifying authentication data precludes
   the use of the mobility header specified in this document, unless
   simple modifications to IPsec (outside the scope of this document)
   can be utilized.  Some suggestions for possible improvements to
   IPsec are included in an appendix, along with descriptions of other
   interactions with IPsec-based verification of mobility messages.

   The requirement is to use of two new header types:  one extension
   header that can be placed before a transport header, and one final
   header type to enable use of IPsec for verifying authentication
   data.  Since an extension header cannot be protected according
   to the strictest interpretation of RFC 2401 [4], and the final
   header type is considered as transport, there is no requirement for
   changing IPsec at all in any node, peer or intermediate.  Since
   these two headers have an identical format, the effect on mobility
   implementation is minimal.

   A node (HA, MN, or CN) MAY request that a sender always send mobility
   control information without data, by indicating "No Piggybacking"
   whenever the underlying security association is established (see
   section 5).  For the return-routability messages specified in in the
   base Mobile IPv6 draft [3], this information can be supplied as a
   option to the Home Address Test message sent back to the mobile node.

   An implementation can have a policy which by default allows
   piggybacking, by means of static configuration.  If there is any
   non-IPsec reason why the node cannot use the Nonfinal Mobility
   Header, the default policy can be disabled by a management interface
   to the policy.  If IPsec is used, this default behavior must be
   disabled.


2. Terminology

   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 [1].  This
   section defines other terminology used that is not already defined
   in [3].

      Piggybacking

         The insertion of two packets from separate message flows or
         sessions is often called "piggybacking".  In this document,




Perkins, Dupont            Expires 15 November 2002             [Page 2]


Internet Draft          Nonfinal Mobility Header           15 April 2002


         piggybacking refers to the insertion of a nonfinal Mobility
         Header into an IPv6 packet that also contains payload.


3. Nonfinal Mobility Message Header Format

   The format of the Nonfinal Mobility Header is identical to the
   format of the final Mobility Header specified in Mobile IPv6 [3].
   In this document, only message types for Binding Update, Binding
   Acknowledgement, and Binding Request are specified as allowable types
   for the Nonfinal Mobility Header.


4. Operation and Use of the Nonfinal Mobility Header

   The basic rule is simple:

    -  If there is an IPsec security association which is established to
       create verification data for binding cache messages, no payload
       may be sent along with any binding cache message.  Use the
       "final" Mobility Header.

    -  Otherwise, payload MAY be sent.  To do so, use the Nonfinal
       Mobility Header specified in section 3, along with the Binding
       Authentication Data option from [3], to validate the message.

   The following subsections detail any necessary elaboration to the
   above rule.


4.1. Rules for the Sender

   The basic rule applies, except that:

      If the correspondent node has requested that no payload
      be included in packets containing a Mobility Header, then
      the mobile node MUST NOT do so.  However, the mobile node
      MAY still Use the Nonfinal Mobility Header along with the
      Binding Authentication Data option, with empty payload.


4.2. Rules for the Correspondent Node

   For the most part, the correspondent node just follows the basic rule
   for any IPv6 extension header [2].  If there exists an IPsec-based
   security association that is to be used when validating binding cache
   messages, the Nonfinal Mobility Header MUST be ignored, and any
   payload processed just as if the Mobility Header were not present.




Perkins, Dupont            Expires 15 November 2002             [Page 3]


Internet Draft          Nonfinal Mobility Header           15 April 2002


   If a correspondent node receives a Nonfinal Mobility Header with
   payload, and if for any reason it would prefer to have the payload
   received in separate packets, the correspondent node SHOULD send an
   ICMP "Piggybacking Control" message back to the mobile node (see
   section 5).  However, in this case, the correspondent node MUST
   NOT drop the packet.  Processing for the contents of the Nonfinal
   Mobility Header is governed by the basic rule, not the existence or
   absence of payload.


5. ICMP Payload Inclusion Control Message

   This specification introduces a new ICMP message type, for use when a
   correspondent node would prefer to control the inclusion of payload
   with the Nonfinal Mobility Header.

   The ICMP "Payload Inclusion Control" has the following format:

    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      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Reserved                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type field is TBD. The Reserved field is sent as zero, and
   ignored on reception.  The Code field can have two valued:

      0        Payload MAY be sent following the Nonfinal Mobility
               Header

      1        Payload MUST NOT be sent following the Nonfinal Mobility
               Header

   See appendix A for discussion about conditions under which a
   correspondent node might utilize such a feature.


6. IANA Considerations

   This specification reserves one extension header number for the
   Nonfinal Mobility Header (see section 3).

   This specification also reserves one ICMP number for the "Payload
   Inclusion Control" ICMP message (see section 5).






Perkins, Dupont            Expires 15 November 2002             [Page 4]


Internet Draft          Nonfinal Mobility Header           15 April 2002


7. Security Considerations

   This document describes a protocol extension header which allows for
   interoperation with IPsec such that the IPsec selector granularity
   requirement for protecting mobility signaling by IPsec headers can be
   expressed in a policy.

   A protocol number reserved as the end header allows for this with
   IPsec while the other protocol number allows for use of the Nonfinal
   Mobility Header for those times when there is no IPsec security
   association governing the validation of binding cache messages.  The
   cache signaling is then protected by the non-IPsec method used with
   route optimization.

   Hence, the proposal solves the ambiguity problem that is result of
   having only a single IPsec header available to protect both the
   payload and the mobility cache management signaling.  Furthermore,
   this proposal enables a very strict interpretation of the clause [4]
   which requires that IPsec policy selection be made only on the basis
   of the final IP header type -- which is often the transport header.
   When IPsec is to be used to validate binding cache messages, even
   the strict interpretation allows IPsec to be used, as long as the
   relevant message data resides in a final header as is specified
   in [3].  However, some implementations would no longer allow payload
   with the IPsec-protected mobility cache signaling.  This proposal
   solves that problem.


8. Acknowledgement

   Appendices B and C were written by Vijay Devarapalli and Jari
   Malinen, who also provided valuable comments on the other parts of
   this draft.


References

   [1] S. Bradner.  Key words for use in RFCs to Indicate Requirement
       Levels.  Request for Comments (Best Current Practice) 2119,
       Internet Engineering Task Force, March 1997.

   [2] S. Deering and R. Hinden.  Internet Protocol, Version 6 (IPv6)
       Specification.  Request for Comments (Draft Standard) 2460,
       Internet Engineering Task Force, December 1998.

   [3] D. Johnson and C. Perkins.  Mobility Support in IPv6 (work in
       progress).  Internet Draft, Internet Engineering Task Force,
       March 2001.




Perkins, Dupont            Expires 15 November 2002             [Page 5]


Internet Draft          Nonfinal Mobility Header           15 April 2002


   [4] S. Kent and R. Atkinson.  Security Architecture for the Internet
       Protocol.  Request for Comments (Proposed Standard) 2401,
       Internet Engineering Task Force, November 1998.


A. Requesting Isolation of Payload and Mobility Headers

   In this discussion, a few fundamental principles should be kept in
   mind:

    -  IP has a MTU which is far larger than the typical capacity of a
       radio bearer channel.  Thus, in order to be IPv6 compliant, the
       device driver for the bearer channel MUST be able to transmit
       larger packets, presumably by a link-layer adaptation that
       fragments and reassembles bearer frames.

       Consequently, requirements related to packet sizing should
       logically be considered as part of a "IP-over-foo" specification,
       and neither part of the base Mobile IPv6 specification, nor this
       specification.  The "piggybacking" ICMP message are provided
       merely for convenience.

    -  IP typically does not distinguish between the delivery of data
       and control information.  Expectations that binding cache control
       information will be delivered out of band, represent assumptions
       which can only be satisfied for particular systems.  Again, the
       logical place to specify protocol details that can enable such
       expectations to be met, would be in a separate "IP-over-foo"
       specification.

    -  If there is a "flow" which needs a certain reserved capacity
       in order to achieve acceptable performance, then the natural
       solution for meeting that need should involve a Quality
       of Service negotiation for that flow, along with admission
       control, and then the subsequent traffic shaping, conditioning,
       and charging.  Any expectation that a specific kind of data
       will be the only allowable data that can flow over a radio
       bearer channel, represents an unwarranted restriction that
       should not persist in any generic IPv6 protocol specification.
       Considerations which are unique for particular platforms or media
       belong in separate "IP-over-foo" specifications.

   It is expected that Mobile IPv6 will be deployed in systems that
   carry voice data over such constrained radio bearer channels.  In
   this situation, it could be that the bearer channel is engineered
   to fit the size of the voice data, and any extra data might cause
   unintended effects.  For convenience, the receiver (i.e., the
   correspondent node) might then send an ICMP "Piggybacking Control"
   to the transmitter (i.e., the mobile node), in order to forestall



Perkins, Dupont            Expires 15 November 2002             [Page 6]


Internet Draft          Nonfinal Mobility Header           15 April 2002


   this possibility.  The binding cache management information would
   then presumably be delivered to the mobile node either during a time
   when no voice data was available, or over an alternate channel.  This
   introduces nontrivial timing dependencies.  In partcular, the mobile
   node SHOULD NOT blindly send out Binding Update messages to all
   correspondent nodes on its Binding List unless there is a reasonable
   expectation that the correspondent node will be sending data to the
   mobile node before the mobile node moves to yeat another point of
   attachment to the Internet.  Furthermore, a method is needed by which
   the mobile node can determine whether the mobility signaling, or
   the application payload data, has priority for transmission to the
   correspondent node, in cases where the mobile node does have some
   data to send.

   Another possibility would be to allow the correspondent node to
   instruct the mobile node about its needs for future binding cache
   message handling by way of conditioning applied to the establishment
   of the security association by which the binding messages are to
   be validated.  This method suffers from the disadvantage that the
   isolation of binding cache messages and payload is no longer able to
   be dynamically controlled.


B. Table of Nonfinal and Final Mobility Header vs IPsec-based Security

   In order to include cache management signaling along with payload
   when IPsec is in use, we have cases 1-4 in Table 1.  We assume
   the current IPsec selectors [4] and two mobility header types for
   mobility signals:  a final header (as defined in [3]), and a nonfinal
   extension header (as defined in section 3).  The node having IPsec
   policies (controlling the insertion of an AH or ESP header) can
   use the nonfinal extension header in cases 1 and 2, that is, when
   mobility signaling does not have an IPsec policy.


         Table 1: Nonfinal Mobility Header Inclusion with IPsec

          IPsec policy for    IPsec policy
          Mobility Message    for Payload        Can piggyback?
     1.       no                 no          |       yes
     2.       no                 yes         |       yes
     3.       yes                no          |       no
     4.       yes                yes         |       no


   In order for the mobility signaling to enforce this, the mobility
   code of a sender needs to know the nature of the security policy
   which controls mobility signaling.  The easiest way to do this is
   to record the information for use within the mobility processing,



Perkins, Dupont            Expires 15 November 2002             [Page 7]


Internet Draft          Nonfinal Mobility Header           15 April 2002


   at the time the security association is set up for this purpose.
   That is very natural, since the security association is itself
   established for mobility management.  In unforeseen cases where no
   such records-keeping is possible, an implementation can make the
   determination even after the security association is set up, as
   follows.  First, construct a mobility signaling packet, making the
   header type final and causing a kernel IPsec policy lookup, in the
   same way as a non-mobility kernel would do.  IPsec already does this
   for any packet.  If no policy exists, the final header type MAY be
   changed to an extension one to indicate that this signal can be
   piggybacked.  If a policy was found, the final header type MUST be
   used.

   A receiver needs no knowledge of mobility in its IPsec processing.
   The header type determines whether a policy even can exist.  If the
   header is final and no policy exists, or a wrong policy exists, the
   packet will be transparently rejected by IPsec.  If the header is
   an extension header, the header type determines that this signal
   cannot have an IPsec policy.  Whether it accepts the extension header
   depends on policy of the non-IPsec protection.

   Piggybacking is not possible on case 3, due to processing
   difficulties at both the sender and the receiver.  The scan for
   transport protocol field as described in [4] does not allow for such
   a mode.  For case 4, conflicting IPsec policies make it impossible to
   piggyback.

   Putting the above together, the sender MAY piggyback for the cases
   1 and 2 in Table 1 and MUST NOT piggyback for cases 3 and 4.  This
   leads directly to the basic rule formulated in section 4.


C. Mobility Signals Which May be Included with Payload

   An implementation sends mobility signaling piggybacked when its
   negotiation result with the peer allows and if it makes sense for the
   mobility signal in question.

   Mobility message types include binding cache management
   messages (BU/BAck/BR) and the return routability test messages
   (HoTI/HoT/CoTI/CoT). Piggybacking of BU/BAck messages between the
   mobile node and its home agent is very rare, since the mobile node
   rarely has any payload for the home agent other than the Binding
   Update itself.  However, the home agent MAY wish to include a
   Binding Request message along with a Router Advertisement in order to
   facilitate renumbering.  Table 2 describes when a mobility signal can
   be included with the payload to be sent between a mobile node (MN)
   and a correspondent node (CN).




Perkins, Dupont            Expires 15 November 2002             [Page 8]


Internet Draft          Nonfinal Mobility Header           15 April 2002


   "Maybe" indicates that piggybacking would be sometimes possible
   (details in the design team writeup).


Addresses

   The working group can be contacted via the current chairs:

      Basavaraj Patil                     Phil Roberts
      Nokia                               Megisto Corp.
      6000 Connection Dr.                 Suite 120
                                          20251 Century Blvd
      Irving, TX. 75039                   Germantown MD 20874
      USA                                 USA
      Phone:  +1 972-894-6709             Phone:  +1 847-202-9314
      Email:  Basavaraj.Patil@nokia.com   Email:  PRoberts@MEGISTO.com


   Questions about this memo can also be directed to the authors:


      Charles E. Perkins                Francis Dupont
      Communications Systems Lab        ENST Bretagne
      Nokia Research Center             Campus de Rennes
      313 Fairchild Drive               2, rue de la Chataigneraie
                                        BP 78
      Mountain View, California 94043   35512 Cesson-Sevigne Cedex
      USA                               FRANCE
      Phone:  +1-650 625-2986
      Fax:  +1 650 625-2502             Fax:  +33 2 99 12 70 30
      EMail:  charliep@iprg.nokia.com   Francis.Dupont@enst-bretagne.fr





















Perkins, Dupont            Expires 15 November 2002             [Page 9]


Internet Draft          Nonfinal Mobility Header           15 April 2002



     Table 2: Mobility Signals and Piggybacking, Assuming No IPsec Policy
                 Controlling Verification of Mobility Messages
      Mobility Message Type          Sndr    Rcvr    Piggyback?
      ---------------------          ----    ----    ----------
      BU (Binding Update)             MN      CN      Yes
      BAck (Binding Acknowledgment)   CN      MN      Yes
      BR (Binding Request)            CN      MN      Yes
      Home Address Test Initiate      MN      CN      Maybe
      Home Address Test               CN      MN      No
      Care-of Address Test Initiate   MN      CN      Maybe
      Care-of Address Test            CN      MN      No








































Perkins, Dupont            Expires 15 November 2002            [Page 10]