Network Working Group                                        G. Tsirtsis
Internet-Draft                                                   V. Park
Intended status: Standards Track                                Qualcomm
Expires: November 5, 2007                                    May 4, 2007


                   GRE-based L2 Tunneling with PMIPv4
                   draft-tsirtsis-l2gre-pmipv4-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.

   This Internet-Draft will expire on November 5, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Tsirtsis & Park         Expires November 5, 2007                [Page 1]


Internet-Draft     GRE-based L2 Tunneling with PMIPv4           May 2007


Abstract

   This specification introduces mechanisms for creating a GRE-based L2
   Tunnel with PMIPv4.


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Flag definition for GRE key Extension  . . . . . . . . . . . .  6
   5.  Initial Registration . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Sending the Registration Request . . . . . . . . . . . . .  7
     5.2.  Receiving the Registration Request . . . . . . . . . . . .  7
     5.3.  Sending the Registration Reply . . . . . . . . . . . . . .  8
     5.4.  Receiving the Registration Reply . . . . . . . . . . . . .  8
     5.5.  Registration Tables  . . . . . . . . . . . . . . . . . . .  9
       5.5.1.  Home Agent . . . . . . . . . . . . . . . . . . . . . .  9
       5.5.2.  Mobility Proxy Agent . . . . . . . . . . . . . . . . .  9
   6.  Reregistrations  . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Registration Request . . . . . . . . . . . . . . . . . . . 10
     6.2.  Registration Reply . . . . . . . . . . . . . . . . . . . . 10
   7.  L2 Tunneling and Address Allocation  . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15























Tsirtsis & Park         Expires November 5, 2007                [Page 2]


Internet-Draft     GRE-based L2 Tunneling with PMIPv4           May 2007


1.  Requirements notation

   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 [RFC2119].














































Tsirtsis & Park         Expires November 5, 2007                [Page 3]


Internet-Draft     GRE-based L2 Tunneling with PMIPv4           May 2007


2.  Introduction

   The Mobile IPv4 (MIPv4) specification [RFC3344] defines optional
   support for GRE tunneling [RFC2784].  Additionally, there is work in
   progress on defining extensions that enable signaling of GRE keys
   [RFC2890] to be used when MIPv4 uses GRE tunneling
   [draft-yegani-gre-key-extension-02.txt], and also work in progress on
   defining mobility management based on Proxy Mobile IPv4 (PMIPv4)
   [draft-leung-mip4-proxy-mode-02.txt].

   The primary use case for [draft-yegani-gre-key-extension-02.txt] is
   the use of GRE keys to support overlapping IPv4 address spaces on the
   same HA.  The mechanisms defined by
   [draft-yegani-gre-key-extension-02.txt] anticipate the use of
   unidirectional GRE keys under the control of the sender i.e., the FA
   (or equivalently the MPA in the case of PMIPv4) indicates (in a
   Registration Request message) the GRE key to be used for reverse
   tunneling, and the HA indicates (in the corresponding Registration
   Reply message) the GRE key to be used for forward tunneling.

   In this document, the mechanisms defined in
   [draft-yegani-gre-key-extension-02.txt] are extended to support the
   use of bidirectional GRE keys under the control of the HA that can be
   MN specific, realm specific, or otherwise.

   Also, the mechanisms defined in this specification allow a GRE-based
   L2 tunnel to be created without necessarily allocating an address to
   the MN.  This allows MNs to use any address configuration mechanism
   they want directly with the HA including, DHCPv4, DHCPv6, Stateless
   Address Autoconfiguration etc.





















Tsirtsis & Park         Expires November 5, 2007                [Page 4]


Internet-Draft     GRE-based L2 Tunneling with PMIPv4           May 2007


3.  Overview

   In this specification, we define that when the Key Identifier field
   in a GRE Key extension [draft-yegani-gre-key-extension-02.txt]
   included in a Registration Request message is set to a predefined
   known value (i.e., "0"), the MPA requests that the HA assign a
   bidirectional GRE key for the given registration.  The HA allocates a
   bidirectional GRE key and returns it in the Key Identifier field of a
   GRE Key extension in the Registration Reply message.  Thus, the value
   of the Key Identifier field returned by the HA is used as the GRE key
   for both forward and reverse tunneled packets.

   The mechanisms defined herein, also allow a GRE-based L2 tunnel to be
   established via PMIPv4.  The MN can then run any address allocation
   procedure, including DHCPv4 and stateless address autoconfiguration
   for IPv6 etc, directly with the HA on which the L2 tunnel terminates.
   To enable this capability, a new flag is defined in the GRE Key
   extension [draft-yegani-gre-key-extension-02.txt], requesting the
   establishment of an GRE-based L2 tunnel.  In that case, the binding
   created in the HA is between a GRE key and a CoA.  This requires the
   use of unidirectional or bidirectional GRE keys that are unique per
   MN.





























Tsirtsis & Park         Expires November 5, 2007                [Page 5]


Internet-Draft     GRE-based L2 Tunneling with PMIPv4           May 2007


4.  Flag definition for GRE key Extension

   The following extension is based on the GRE Key extension defined in
   [draft-yegani-gre-key-extension-02.txt].  This specification defines
   the "A" flag shown below, from within the field previously defined as
   Reserved.

        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      |   Length      |A|         Reserved            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Key Identifier                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      See [draft-yegani-gre-key-extension-02.txt]

   Length

      See [draft-yegani-gre-key-extension-02.txt]

   A

      Requests GRE-based L2 Tunneling Mode

   Reserved

      See [draft-yegani-gre-key-extension-02.txt]

   Key Identifier

      See [draft-yegani-gre-key-extension-02.txt]

















Tsirtsis & Park         Expires November 5, 2007                [Page 6]


Internet-Draft     GRE-based L2 Tunneling with PMIPv4           May 2007


5.  Initial Registration

5.1.  Sending the Registration Request

   According to [draft-yegani-gre-key-extension-02.txt], an FA (or
   presumably MPA) can send a Registration Request message with a GRE
   Key extension to request use of GRE keys as part of GRE tunneling.
   This specification allows the sender of a Registration Request
   message with a GRE Key extension to further request the use a GRE-
   based L2 tunnel by setting the "A" flag as follows:

      "0" Indicates normal GRE Tunneling Mode.

      "1" Indicates GRE-based L2 Tunneling Mode.  In this case the Key
      Identifier(s) corresponding to the registration MUST be unique per
      MN.

   In accordance with this specification, the MPA can also request the
   use of a bidirectional key according to value of the Key Identifier
   field of the GRE Key extension in the Registration Request message:

      When the Key Identifier field is set to "0" the sender requests a
      bidirectional GRE key to be defined by the HA.

      When the Key Identifier field is set to any other value, it
      indicates the value of the GRE key to be used for tunneling from
      the MPA to the HA.

5.2.  Receiving the Registration Request

   The following defines GRE Key extension processing to be performed by
   the HA in addition to that described in
   [draft-yegani-gre-key-extension-02.txt].

   If in a Registration Request message with a GRE Key extension, the
   Key Identifier field is set to "0" and the A flag is set to "0", then
   the HA MUST allocate a bidirectional GRE key, which need not be
   unique per MN.  The allocated bidirectional GRE key MAY be realm
   specific or otherwise based on HA policy.

   If in a Registration Request message with a GRE Key extension, the
   Key Identifier is set to a value other than "0" and A flag is set to
   "0", then the HA SHOULD accept the value of the Key Identifier field
   as the GRE key to be used for reverse tunneling from the MPA to the
   HA and allocate a unidirectional GRE key, which need not be unique
   per MN, to be used for forward tunneling.  The allocated
   unidirectional GRE key MAY be realm specific or otherwise based on HA
   policy.



Tsirtsis & Park         Expires November 5, 2007                [Page 7]


Internet-Draft     GRE-based L2 Tunneling with PMIPv4           May 2007


   If in a Registration Request message with a GRE Key extension, the
   Key Identifier is set to "0" and the A flag is set to "1", then the
   HA MUST allocate a bidirectional GRE key, which MUST be unique per
   MN.  In this case the HA, creates an L2 tunnel for the MN and
   maintains a binding between the bidirectional GRE key and the CoA of
   the MN.

   If in a Registration Request message with a GRE Key extension, the
   Key Identifier is set to a value other than "0" and the A flag is set
   to "1", then the HA SHOULD accept the value of the Key Identifier
   field as the GRE key to be used for reverse tunneling from the MPA to
   the HA and allocate a unidirectional GRE key, which MUST be unique
   per MN, to be used for forward tunneling.  In this case the HA,
   creates an L2 tunnel for the MN and maintains a binding between the
   GRE keys for each direction and the CoA of the MN.

5.3.  Sending the Registration Reply

   Provided a Registration Request message with a GRE Key extension is
   accepted, the HA MUST include a GRE Key extension in the
   corresponding Registration Reply message.  In all cases, the Key
   Identifier field of the GRE Key extension included in the
   Registration Reply message is set to the value of the GRE key
   allocated by the HA in response to the corresponding Registration
   Request message.  The A flag of the GRE Key extension included in the
   Registration Reply message is set to the same value as the A flag of
   the corresponding Registration Request message.

   If the GRE key extension is not accepted by the HA, the Registration
   Request SHOULD be rejected with an appropriate rejection code e.g.,
   Administratively Prohibited, as per [RFC3344].

5.4.  Receiving the Registration Reply

   Provided a Registration Request message with a GRE Key extension is
   accepted, the Registration Reply message will also include a GRE key
   extension.

   If the GRE key extension in the Registration Request message included
   a Key Identifier value of "0" then, the receiver of this message MUST
   accept the value of the Key Identifier field in the GRE key extension
   in the Registration Reply message as the bidirectional GRE key to be
   used for this MN.

   If the GRE key extension in the Registration Request message included
   a Key Identifier value other than "0" then, the receiver of this
   message MUST accept the value of the Key Identifier field in the GRE
   key extension in the Registration Reply message as the GRE key to be



Tsirtsis & Park         Expires November 5, 2007                [Page 8]


Internet-Draft     GRE-based L2 Tunneling with PMIPv4           May 2007


   used for this MN in the forward direction.

5.5.  Registration Tables

5.5.1.  Home Agent

   In addition to what is defined in [RFC3344], Section 3.8.1., the
   following information needs to be retained by the HA:

      - the mobile node's GRE key in the reverse direction

      - the mobile node's GRE key in the forward direction

   Also note that unlike what is indicated in the same section of
   [RFC3344], in some cases the HoA may not be known.

5.5.2.  Mobility Proxy Agent

   While not explicitly outlined in
   [draft-leung-mip4-proxy-mode-02.txt], an MPA must maintain
   information associated with registrations.  In addition to what is
   required in support of [draft-leung-mip4-proxy-mode-02.txt], the
   following information needs to be retained by the MPA:

      - the mobile node's GRE key in the reverse direction

      - the mobile node's GRE key in the forward direction
























Tsirtsis & Park         Expires November 5, 2007                [Page 9]


Internet-Draft     GRE-based L2 Tunneling with PMIPv4           May 2007


6.  Reregistrations

6.1.  Registration Request

   The MPA SHOULD include the GRE Key extension in all reregistrations.
   If the GRE key, set-up by an earlier MPA, is known, it SHOULD be
   included in the Key Identifier field of the extension.  If the GRE
   key is not known or a different one needs to be negotiated, the
   reregistration message has to follow the same rules with the initial
   registration message defined in Section 5.1.

6.2.  Registration Reply

   Assuming the subsequent Registration Request message includes a GRE
   key extension that reflects the negotiated GRE key, the HA simply
   copies the extension to the Registration Reply.

   If the GRE key extension included in the subsequent Registration
   Request does not reflect the agreed key, the request will have the
   same effect as the initial request and the HA MUST treat it as in
   Section 5.2 and the reply MUST be formed as defined in Section 5.3.






























Tsirtsis & Park         Expires November 5, 2007               [Page 10]


Internet-Draft     GRE-based L2 Tunneling with PMIPv4           May 2007


7.  L2 Tunneling and Address Allocation

   When a GRE-based L2 tunnel is requested (the A flag in the GRE key
   extension is set to "1", see Section 5.1), the binding communicated
   by the Registration Request message is between the GRE key(s) and the
   CoA rather than an HoA and the CoA.

   Unlike [RFC3344], in this case, if the HoA field of the Registration
   Request message is set to "0", the HA is NOT REQUIRED to allocate an
   IP Address in the Registration Reply message.  Instead the HA MAY
   also set the HoA field in the Registration Reply message to "0".

   Also, when L2 Tunneling is used as defined in this specification, the
   MN MAY use DHCPv4, DHCPv6, IPv6 Address Autoconfiguration or any
   other mechanism directly with the HA, to configure its addresses.
   After addresses have been allocated, the MN MAY register them with
   the HA using appropriate MIPv4 mechanisms.


































Tsirtsis & Park         Expires November 5, 2007               [Page 11]


Internet-Draft     GRE-based L2 Tunneling with PMIPv4           May 2007


8.  Security Considerations

   This specification operates in the security constraints and
   requirements of the underlying protocols.















































Tsirtsis & Park         Expires November 5, 2007               [Page 12]


Internet-Draft     GRE-based L2 Tunneling with PMIPv4           May 2007


9.  Normative References

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

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, September 2000.

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





































Tsirtsis & Park         Expires November 5, 2007               [Page 13]


Internet-Draft     GRE-based L2 Tunneling with PMIPv4           May 2007


Authors' Addresses

   George Tsirtsis
   Qualcomm

   Phone: +908-443-8174
   Email: tsirtsis@qualcomm.com


   Vincent Park
   Qualcomm

   Phone: +908-443-8141
   Email: vpark@qualcomm.com





































Tsirtsis & Park         Expires November 5, 2007               [Page 14]


Internet-Draft     GRE-based L2 Tunneling with PMIPv4           May 2007


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





Tsirtsis & Park         Expires November 5, 2007               [Page 15]