Network Working Group                                      Y. El Mghazli
Internet-Draft                                                   Alcatel
Intended status: Standards Track                        October 16, 2006
Expires: April 19, 2007


                       MIPv4 tunneling extensions
                    draft-yacine-mip4-tunnel-ext-00

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 April 19, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).














El Mghazli               Expires April 19, 2007                 [Page 1]


Internet-Draft         MIPv4 tunneling extensions           October 2006


Abstract

   Mobile IPv4 lacks the capability to dynamically configure the tunnel
   type and to configure tunnel-specific options and parameters.  This
   document describes a new MIPv4 registration extension that allows a,
   mobile node or a foreign agent to provide tunnel information to the
   home agent.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Tunneling extension  . . . . . . . . . . . . . . . . . . . . .  4
   3.  Tunneling Sub-Types  . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  GRE Tunneling  . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  IP-in-IP Tunneling . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Minimal Encapsulation  . . . . . . . . . . . . . . . . . .  6
   4.  Processing of Tunneling extension  . . . . . . . . . . . . . .  7
     4.1.  Foreign Agent considerations . . . . . . . . . . . . . . .  7
     4.2.  Home Agent considerations  . . . . . . . . . . . . . . . .  7
   5.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13























El Mghazli               Expires April 19, 2007                 [Page 2]


Internet-Draft         MIPv4 tunneling extensions           October 2006


1.  Introduction

   When a mobile node detects that it has moved to a foreign network, it
   obtains a care-of address on the foreign network.  The care-of
   address can either be determined from a foreign agent's
   advertisements (a foreign agent care-of address), or by some external
   assignment mechanism such as DHCP [RFC2131] (a co-located care-of
   address).

   The mobile node operating away from home then registers its new
   care-of address with its home agent through exchange of a
   Registration Request and Registration Reply message with it, possibly
   via a FA.

   Datagrams sent to the mobile node's home address are intercepted by
   its home agent, tunneled by the home agent to the mobile node's
   care-of address, received at the tunnel endpoint (either at a foreign
   agent or at the mobile node itself), and finally delivered to the
   mobile node.

   As per [RFC3344], the tunneling type is specified by the MN, using
   flags when sending its Registration Request.

   This document defines a MIPv4 registration extension that allows the
   MN and/or the FA to provide additional tunneling information to the
   HA.

























El Mghazli               Expires April 19, 2007                 [Page 3]


Internet-Draft         MIPv4 tunneling extensions           October 2006


2.  Tunneling extension

   This section defines the Tunneling Extension which may be used in
   Mobile IP Registration Request and Reply messages.  The extension may
   be used by a mobile node or a foreign agent that wants to specify
   tunneling options associated to a given tunneling type.  This
   document also defines some subtype numbers which identify the
   specific type of tunnel in Section 3.  It is expected that other
   types of NAI tunnels will be defined by other documents in the
   future.

   The extension has the format shown in this section to carry
   configuration information.


       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      |    Sub-Type     |            Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Options
      +-+-+-+-+-+-...

   Type:

      IPV4-TUNNEL-EXT-TYPE to be assigned by IANA (skippable)

   Sub-Type:

      indicates the particular type of tunneling.

   Length:

      indicates the length (in bytes) of the Options field within this
      extension.  The length does NOT include the Type, Length and Sub-
      Type bytes.

   Options:

      contains the configuration parameters that will be used to
      transmit information related to sub-type value option.










El Mghazli               Expires April 19, 2007                 [Page 4]


Internet-Draft         MIPv4 tunneling extensions           October 2006


3.  Tunneling Sub-Types

3.1.  GRE Tunneling

   The GRE tunneling uses subtype GRE-SUB-TYPE (to be assigned by IANA)
   of the Tunneling Extension.  This sub-type is used to request the use
   of GRE encapsulation [RFC1701] by the home agent.  In addition, the
   Options field MAY be used to request the use of a particular GRE key
   and possibly to activate GRE sequence number usage.

   The GRE Tunneling Options field 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   |K|S|                      Reserved                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Key-Identifier (optional)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Key Support (bit 2):

      indicates that the Key-Identifier field is present in the GRE
      tunneling extension.  Otherwise, the Key identifier is not
      present.

   Sequence Number Support (bit 3):

      indicates the home agent will insert a sequence number field in
      each GRE packets, as per [RFC1701].  Otherwise the sequence number
      GRE extension will not be used by the home agent.

   Key-Identifier:

      contains a four octet number which will be inserted by the home
      agent in each GRE packets, as per [RFC1701].  The Key field is
      intended to be used for identifying an individual traffic flow
      within a tunnel.

3.2.  IP-in-IP Tunneling

   The IP-in-IP tunneling uses subtype IP-IN-IP-SUB-TYPE (to be assigned
   by IANA) of the Tunneling Extension.  This sub-type is used to
   request the use of IP-in-IP encapsulation [RFC2003] by the home
   agent.  No Options field is associated with IP-in-IP tunneling
   extention.




El Mghazli               Expires April 19, 2007                 [Page 5]


Internet-Draft         MIPv4 tunneling extensions           October 2006


3.3.  Minimal Encapsulation

   The Min-IP tunneling uses subtype MIN-IP-SUB-TYPE (to be assigned by
   IANA) of the Tunneling Extension.  This sub-type is used to request
   the use of minimal encapsulation [RFC2004] by the home agent.  No
   Options field is associated with Minimal encapsulation extention.













































El Mghazli               Expires April 19, 2007                 [Page 6]


Internet-Draft         MIPv4 tunneling extensions           October 2006


4.  Processing of Tunneling extension

4.1.  Foreign Agent considerations

   Mobile IP defines two different registration procedures, one directly
   with the mobile node's home agent, and one via a foreign agent that
   relays the registration to the mobile node's home agent.

   Indeed, if a mobile node is registering a foreign agent care-of
   address or if a mobile node is using a co-located care-of address,
   and receives an Agent Advertisement (with 'R' bit set) from a FA on
   the link on which it is using this care-of address, the mobile node
   will register via that foreign agent.

   In this latter case, after reception of the Registration Request from
   the MN, the FA MAY itself mandate the use of a specific tunneling
   type and specify the associated configuration options by inserting
   the tunneling extension in the Registration Request.

   In case the Registration Request already contains a tunneling
   extension, sent by the mobile node, the FA can replace the existing
   extension by a new one, hence mandating the use of another tunneling
   technology and/or other tunneling options.

4.2.  Home Agent considerations

   After reception of the Registration Request, the HA must analyse the
   tunnel-type in order to validate or not the FA tunnel proposal.  If
   the tunnel type is accepted, the HA should also add a tunnel option
   extension in the registration reply, with the same tunnel-type.

   If the tunnel-type is refused from the HA, it must also add a tunnel
   option extension in the Registration Reply, and indicating the tunnel
   type it has chosen.

   The sub-type must only be used and analysed by HA when tunnel-type is
   accepted by the HA.  The sub-type must only be inserted in the
   Registration Reply, when the tunnel-type proposed by FA is accepted
   by HA.

   In case the use of 'G' or 'M' bit, set by the mobile node, in the
   Registration Request are inconsistent with the information contained
   in the Tunneling extension, the home agent MUST consider only the
   information contained in the extension.







El Mghazli               Expires April 19, 2007                 [Page 7]


Internet-Draft         MIPv4 tunneling extensions           October 2006


5.  IANA considerations

   This draft defines the following values:

   IPV4-TUNNEL-EXT-TYPE:

      new Mobile IPv4 extension as defined in Section 2 of this
      document.  This value MUST be assigned by IANA from the Mobile IP
      numbering space for skippable extensions.

   GRE-SUB-TYPE

   IP-IN-IP-SUB-TYPE

   MIN-IP-SUB-TYPE




































El Mghazli               Expires April 19, 2007                 [Page 8]


Internet-Draft         MIPv4 tunneling extensions           October 2006


6.  Security considerations

   There are no additional security aspects imposed by this document in
   addition to the one defined in [RFC3344].















































El Mghazli               Expires April 19, 2007                 [Page 9]


Internet-Draft         MIPv4 tunneling extensions           October 2006


7.  Acknowledgments

   Jean-Pierre Rombeaut.
















































El Mghazli               Expires April 19, 2007                [Page 10]


Internet-Draft         MIPv4 tunneling extensions           October 2006


8.  References

8.1.  Normative References

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

   [RFC1701]  Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
              Routing Encapsulation (GRE)", RFC 1701, October 1994.

8.2.  Informative References

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
              October 1996.

   [RFC2004]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
              October 1996.































El Mghazli               Expires April 19, 2007                [Page 11]


Internet-Draft         MIPv4 tunneling extensions           October 2006


Author's Address

   Yacine El Mghazli
   Alcatel
   Route de Nozay
   Marcoussis  91460
   France

   Email: yacine.el_mghazli@alcatel.fr










































El Mghazli               Expires April 19, 2007                [Page 12]


Internet-Draft         MIPv4 tunneling extensions           October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


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).





El Mghazli               Expires April 19, 2007                [Page 13]