[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-muhanna-netlmm-grekey-option) 00 01 02 03 04 05 06 07 08 09 RFC 5845

Network Working Group                                         A. Muhanna
Internet-Draft                                                 M. Khalil
Intended status: Standards Track                                  Nortel
Expires: August 28, 2009                                   S. Gundavelli
                                                                K. Leung
                                                           Cisco Systems
                                                       February 24, 2009


                  GRE Key Option for Proxy Mobile IPv6
                 draft-ietf-netlmm-grekey-option-06.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 August 28, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.





Muhanna, et al.          Expires August 28, 2009                [Page 1]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


Abstract

   This specification defines a new Mobility Option for allowing the
   mobile access gateway and the local mobility anchor to negotiate GRE
   (Generic Routing Encapsulation) encapsulation mode and exchange the
   downlink and uplink GRE keys which are used for marking the downlink
   and uplink traffic that belong to a specific mobility session.  In
   addition, the same mobility option can be used to negotiate the GRE
   encapsulation mode without exchanging the GRE keys.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions & Terminology  . . . . . . . . . . . . . . . . . .  4
     2.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  GRE Encapsulation and Keys Exchange  . . . . . . . . . . . . .  5
     3.1.  GRE Encapsulation Overview . . . . . . . . . . . . . . . .  5
     3.2.  GRE Encapsulation Mode Only  . . . . . . . . . . . . . . .  7
     3.3.  GRE Encapsulation and Keys Exchange  . . . . . . . . . . .  7
       3.3.1.  Initial GRE Key Exchange . . . . . . . . . . . . . . .  7
       3.3.2.  GRE Key Exchange During Binding Re-registration  . . .  8
   4.  Mobile Access Gateway Considerations . . . . . . . . . . . . .  9
     4.1.  Extensions to the Conceptual Data Structure  . . . . . . .  9
     4.2.  Operational Summary  . . . . . . . . . . . . . . . . . . .  9
   5.  Local Mobility Anchor Considerations . . . . . . . . . . . . . 11
     5.1.  Extensions to the Binding Cache Entry  . . . . . . . . . . 11
     5.2.  Operational Summary  . . . . . . . . . . . . . . . . . . . 11
   6.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 13
     6.2.  Proxy Binding Update Message Extension . . . . . . . . . . 14
     6.3.  Proxy Binding Acknowledgement Message Extension  . . . . . 14
     6.4.  Status Codes . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Data Packets Processing Considerations . . . . . . . . . . . . 16
     7.1.  Tunneling Format . . . . . . . . . . . . . . . . . . . . . 16
     7.2.  TLV-header Tunneling Negotiation . . . . . . . . . . . . . 17
     7.3.  Mobile Access Gateway Operation  . . . . . . . . . . . . . 18
       7.3.1.  Sending and Receiving Data Packets . . . . . . . . . . 19
     7.4.  Local Mobility Anchor Operation  . . . . . . . . . . . . . 20
       7.4.1.  Sending and Receiving Data Packets . . . . . . . . . . 20
     7.5.  Mobile Node Operation  . . . . . . . . . . . . . . . . . . 21
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     11.2. Informative References . . . . . . . . . . . . . . . . . . 23



Muhanna, et al.          Expires August 28, 2009                [Page 2]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23


















































Muhanna, et al.          Expires August 28, 2009                [Page 3]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


1.  Introduction

   Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile IPv6
   support for IPv4 [ID-PMIP6-IPv4] allow the use of IPv6 and IPv4
   encapsulation modes [RFC2473][RFC2003] for the tunneled traffic
   between the local mobility anchor and the mobile access gateway.
   There are scenarios where these encapsulation modes are not
   sufficient to uniquely identify the destination of packets of a
   specific mobility session.  Thus, there is a need for an
   encapsulation mode with richer semantics.  The Generic Routing
   Encapsulation (GRE) [RFC2784] and the Key extension as defined in
   [RFC2890], has the required semantics to allow such distinction for
   use in Proxy Mobile IPv6.

   This specification defines the GRE Key option to be used for the
   negotiation of GRE encapsulation mode and exchange of the uplink and
   downlink GRE keys.  The negotiated downlink and uplink GRE keys can
   be used for marking the downlink and uplink traffic for a specific
   mobility session.  In addition, this specification enables the mobile
   access gateway and the local mobility anchor to negotiate the use of
   GRE encapsulation mode without exchanging the GRE keys.


2.  Conventions & Terminology

2.1.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   specification are to be interpreted as described in RFC 2119
   [RFC2119].

2.2.  Terminology

   All the general mobility related terminology and abbreviations are to
   be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile
   IPv6 [RFC5213] specifications.  The following terms are used in this
   specification.

   Downlink Traffic

      The traffic in the tunnel between the local mobility anchor and
      the mobile access gateway, heading towards the mobile access
      gateway and tunneled at the local mobility anchor.  This traffic
      is also called forward direction traffic.






Muhanna, et al.          Expires August 28, 2009                [Page 4]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


   Uplink Traffic

      The traffic in the tunnel between the mobile access gateway and
      the local mobility anchor, heading towards the local mobility
      anchor and tunneled at the mobile access gateway.  This traffic is
      also called reverse direction traffic.

   Downlink GRE Key

      The GRE key is assigned by the mobile access gateway and used by
      the local mobility anchor to mark the downlink traffic which
      belongs to a specific mobility session as described in this
      specification.

   Uplink GRE Key

      The GRE key is assigned by the local mobility anchor and used by
      the mobile access gateway to mark the uplink traffic which belongs
      to a specific mobility session as described in this specification.

   A Policy Check

      When LMA receives an initial, handoff-triggered Binding Lifetime
      Extension, or Binding Lifetime Extension Proxy Binding Update for
      a mobility session, the LMA determines if the GRE encapsulation
      mode only or GRE encapsulation and GRE keys are required based on
      a policy check.  This policy could be a per MAG-LMA pair, a per-
      LMA local policy, a per-MN policy, or the combination of any of
      them.


3.  GRE Encapsulation and Keys Exchange

3.1.  GRE Encapsulation Overview

   Using the GRE Key option defined in this specification, the mobile
   access gateway and the local mobility anchor can negotiate GRE
   encapsulation mode only or GRE encapsulation mode and exchange the
   GRE keys for marking the downlink and uplink traffics.  In the case
   when GRE encapsulation mode only is negotiated between the MAG and
   the LMA, then no GRE keys are used.

   However, once the GRE keys have been exchanged between the mobile
   access gateway and the local mobility anchor as per this
   specification, the mobile access gateway will use the uplink GRE key
   that is assigned by the local mobility anchor in the GRE header of
   the uplink payload packet.  Similarly, the local mobility anchor will
   use the downlink GRE key as negotiated with the mobile access gateway



Muhanna, et al.          Expires August 28, 2009                [Page 5]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


   in the GRE header of the downlink payload packet.

   The following illustration explains the use of GRE encapsulation mode
   and the GRE keys for supporting the usecase where overlapping IPv4
   private address [RFC1918] allocation is in use.




                                                          +------------+
                                                          | Operator-A |
                                                          |            |
                                                          | 10.x.0.0/16|
                                                          +------------+
                                                                   /
        +------+                                      +------+    /
        |      |      ==========================      |      |   /
 MN-1---|      |    /                            \    |      |  / Key-1
        |  M   |   / ---Flows with GRE Key-1 ---- \   |  L   | / Traffic
 MN-2---|  A   |--|                                |--|  M   |-
        |  G   |   \ ---Flows with GRE Key-2 ---- /   |  A   | \ Key-2
 MN-3---|      |    \                            /    |      |  \Traffic
        |      |      ==========================      |      |   \
 MN-4---|      |       Proxy Mobile IPv6 Tunnel       |      |    \
        +------+                                      +------+     \
                                                                    \
                   Operator-C: Access Network             +------------+
                                                          | Operator-B |
                                                          |            |
                                                          | 10.x.0.0/16|
                                                          +------------+



    Figure 1: GRE Tunneling for IPv4 Private Address Space Overlapping



   Figure 1 illustrates a local mobility anchor providing mobility
   service to mobile nodes that are from different operators and are
   assigned IPv4 addresses from overlapping private address space.  In
   this scenario, the mobile access gateway and the local mobility
   anchor must be able to distinguish the flows belonging to a given
   operator from the flows belonging to some other operator.

   The mobile nodes, MN-1 and MN-2 are visiting from Operator-A, and
   mobile nodes, MN-3 and MN-4 are visiting from Operator-B.  The mobile
   access gateway and the local mobility anchor exchange a specific pair



Muhanna, et al.          Expires August 28, 2009                [Page 6]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


   of downlink and uplink GRE keys and save them as part of the mobile
   node binding to be used for identifying the flows belonging to each
   mobile node.

   The LMA and the MAG will be able to distinguish each mobile node
   flow(s) based on the GRE key present in the GRE header of the
   tunneled payload packet, and route them accordingly.  However, the
   GRE keys as in this specification apply to the individual mobility
   binding updated by the Proxy Binding Update but not to all bindings
   that the mobile may have registered following procedures described in
   [ID-MCoA].

3.2.  GRE Encapsulation Mode Only

   In order for the mobile access gateway to request GRE encapsulation
   mode only without exchanging the GRE keys, the mobile access gateway
   MUST include the GRE Key option but omit the GRE Key Identifier field
   in the Proxy Binding Update.

   If the local mobility anchor supports GRE encapsulation and the
   received Proxy Binding Update contains the GRE Key option but the GRE
   Key Identifier field is omitted, the mobile access gateway is
   requesting GRE encapsulation without exchanging the GRE keys
   dynamically.  If the Proxy Binding Update processing is successful,
   the LMA sends a successful Proxy Binding Acknowledgement message with
   the GRE Key option but the GRE Key Identifier field is omitted.

   When the mobile access gateway and the local mobility anchor
   successfully negotiate the GRE encapsulation mode only, then no GRE
   keys are used.

3.3.  GRE Encapsulation and Keys Exchange

   The following subsections describe how the mobile access gateway and
   the local mobility anchor negotiate GRE encapsulation and exchange
   downlink and uplink GRE keys using proxy mobile IPv6 registration
   procedure.

3.3.1.  Initial GRE Key Exchange

   When the mobile access gateway determines, based on, e.g., private
   IPv4 address support [RFC1918], the MAG local policy, or the MAG-LMA
   peer agreement, that GRE encapsulation is needed and GRE keys are
   required, the mobile access gateway MUST include the GRE Key option
   in the initial Proxy Binding Update message sent to the local
   mobility anchor.  The mobile access gateway MUST include the downlink
   GRE key in the GRE Key Identifier field of the GRE Key option.




Muhanna, et al.          Expires August 28, 2009                [Page 7]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


   After the LMA successfully processes the initial Proxy Binding Update
   and accepts the GRE encapsulation request and the downlink GRE key
   based on a policy check, the LMA MUST include the GRE Key option with
   the uplink GRE key in the GRE Key Identifier field in a successful
   Proxy Binding Acknowledgement and send it to the MAG.

3.3.2.  GRE Key Exchange During Binding Re-registration

   If the MAG has successfully negotiated and exchanged the initial GRE
   keys with the LMA for a specific mobile node binding, the MAG MUST
   include the GRE Key option with the downlink GRE key in the Proxy
   Binding Update which is used for requesting a Binding Lifetime
   Extension.

   However, during inter-MAG handoff and if the new mobile access
   gateway determines, based on, e.g., private IPv4 address support, the
   MAG local policy, the MAG-LMA peer agreement, or an indication during
   the handoff process, that GRE encapsulation and GRE keys exchange are
   required, the new mobile access gateway MUST include the GRE key
   option with the downlink GRE key in the Proxy Binding Update which is
   used for requesting an after handoff Binding Lifetime extension.  In
   this case, the new MAG may either pick a new downlink GRE key or use
   the downlink GRE key that was used by the previous MAG for the same
   binding.  For the new MAG to know the downlink GRE key used by the
   previous MAG, it may require transfer of context from the previous
   MAG to the new MAG during a handoff.  Such mechanisms are out-of-
   scope for this specification.

   If the LMA successfully processes a handoff-triggered Binding
   Lifetime Extension Proxy Binding Update message which contains a GRE
   key option with a downlink GRE key included, the LMA MUST return the
   same uplink GRE key that was exchanged with the previous MAG for the
   same mobility session in the GRE key option in a successful Proxy
   Binding Acknowledgement message sent to the new MAG.

   If the LMA receives a handoff-triggered Binding Lifetime Extension
   Proxy Binding Update message without the GRE key option for a BCE
   that is using GRE keys and GRE encapsulation, the LMA makes a policy
   check regarding GRE encapsulation and GRE keys exchange.  If,
   according to the policy check, GRE encapsulation and GRE Keys
   exchange are required, the LMA MUST reject the Proxy Binding Update
   by sending a Proxy Binding Acknowledgement message with the status
   field is set to <GRE KEY OPTION REQUIRED> as defined in Section 6.4.
   Otherwise, the LMA SHOULD accept the Proxy Binding Update and if it
   is processed successfully, the LMA MUST return a successful Proxy
   Binding Acknowledgement without including the GRE Key option.





Muhanna, et al.          Expires August 28, 2009                [Page 8]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


4.  Mobile Access Gateway Considerations

4.1.  Extensions to the Conceptual Data Structure

   Every mobile access gateway maintains a Binding Update List (BUL)
   entry for each currently attached mobile node, as explained in
   Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213].  To
   support this specification, the conceptual Binding Update List entry
   data structure must be extended with the following three new
   additional fields.

   o  A flag indicating whether GRE encapsulation is enabled for the
      mobile node's traffic.

   o  The downlink GRE key used in the GRE encapsulation header of the
      tunneled payload packet from the local mobility anchor to the
      mobile access gateway that is destined to the mobile node.  This
      GRE key is generated by the MAG and communicated to the LMA in the
      GRE Key option in the Proxy Binding Update message.

   o  The uplink GRE key used in the GRE encapsulation header of the
      tunneled payload packet from the mobile access gateway to the
      local mobility anchor that is originating from the mobile node.
      This GRE key is obtained from the GRE Key Identifier field of the
      GRE Key option present in the received Proxy Binding
      Acknowledgement message sent by the LMA as specified in this
      specification.

4.2.  Operational Summary

   o  If the MAG determines that GRE encapsulation mode only is
      required, the MAG MUST include the GRE Key option but omit the GRE
      Key Identifier field in the Proxy Binding Update message that is
      sent to the local mobility anchor.

   o  If the MAG determines that GRE encapsulation and GRE keys are
      required, the MAG MUST include the GRE Key option with the
      downlink GRE key in the GRE Key Identifier field in the Proxy
      Binding Update message that is sent to the local mobility anchor.

   o  After receiving a successful Proxy Binding Acknowledgment message
      with the GRE Key option with the GRE Key Identifier field omitted,
      the mobile access gateway MUST update the mobile node Binding
      Update List entry described in Section 4.1 by only setting the GRE
      encapsulation enabled flag.






Muhanna, et al.          Expires August 28, 2009                [Page 9]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


   o  After receiving a successful Proxy Binding Acknowledgment message
      with the GRE Key option and the uplink GRE key included in the GRE
      Key Identifier field, the mobile access gateway MUST update the
      related three fields in the mobile node Binding Update List entry
      described in Section 4.1.  Additionally, the MAG MUST use the
      assigned uplink GRE Key for tunneling all the traffic that belong
      to this mobile node BUL entry and is originated from the mobile
      node before forwarding the tunneled traffic to the LMA.

   o  If the mobile access gateway includes the GRE Key option in the
      Proxy Binding Update for a specific mobile node and the local
      mobility anchor accepts the Proxy Binding Update by sending a
      Proxy Binding Acknowledgement with a success status code (less
      than 128) other than <GRE KEY OPTION NOT REQUIRED>, but without
      the GRE Key option, then the mobile access gateway MUST consider
      that the local mobility anchor does not support GRE Key option as
      per this specification.  The mobile access gateway SHOULD NOT
      include the GRE Key option in any subsequent Proxy Binding Update
      message that is sent to that LMA.

   o  If the mobile access gateway sent a Proxy Binding Update message
      without the GRE Key option, but the received Proxy Binding
      Acknowledgement has the Status Code <GRE KEY OPTION REQUIRED>,
      indicating that the GRE encapsulation and GRE key is required, the
      mobile access gateway SHOULD resend the Proxy Binding Update
      message with the GRE Key option.  If the MAG does not support the
      GRE Key option, the MAG MAY log the event and possibly raise an
      alarm to indicate a possible misconfiguration.

   o  If the mobile access gateway sent a Proxy Binding Update message
      with the GRE Key option and the downlink GRE key included and
      received a successful Proxy Binding Acknowledgement message with a
      status code <GRE KEY OPTION NOT REQUIRED>, the mobile access
      gateway MUST consider that GRE encapsulation and GRE keys is not
      required for this specific mobility session.  The MAG follows
      procedures in Proxy Mobile IPv6 specification [RFC5213] for the
      handling of uplink and downlink traffic and MUST NOT include the
      GRE Key option in any subsequent Proxy Binding Update message that
      is sent to the LMA for this mobility session.

   o  If the MAG has successfully negotiated GRE encapsulation and
      exchanged the GRE keys with the LMA for a specific mobility
      session, the MAG SHOULD NOT include the GRE Key option in the de-
      registration Proxy Binding Update.

   o  On receiving a packet from the tunnel with the GRE header, the
      mobile access gateway MUST use the GRE Key present in the GRE
      extension header as an additional identifier to determine which



Muhanna, et al.          Expires August 28, 2009               [Page 10]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


      mobility session this packet belongs to.  The GRE header is
      removed before further processing takes place.


5.  Local Mobility Anchor Considerations

5.1.  Extensions to the Binding Cache Entry

   When the local mobility anchor and the mobile access gateway
   successfully negotiate GRE encapsulation and exchange downlink and
   uplink GRE keys, the local mobility anchor MUST maintain the downlink
   and uplink GRE keys as part of the mobile node BCE.  This requires
   that the BCE described in section 5.1 of the Proxy Mobile IPv6
   specification [RFC5213] to be extended.  To support this
   specification, the BCE must be extended with the following three
   additional fields.

   o  A flag indicating whether GRE encapsulation is enabled for the
      mobile node's traffic flows.

   o  The downlink GRE Key, assigned by the MAG and used in the GRE
      encapsulation header of the tunneled payload packet from the local
      mobility anchor to the mobile access gateway.

   o  The Uplink GRE Key, assigned by the LMA and used in the GRE
      encapsulation header of the tunneled payload packet from the
      mobile access gateway to the local mobility anchor.

5.2.  Operational Summary

   o  If local mobility anchor successfully processes a Proxy Binding
      Update message with the GRE Key option but the GRE Key Identifier
      field is omitted for Initial GRE Key exchange, the local mobility
      anchor MUST include the GRE Key option but omit the GRE Key
      Identifier field when responding with a successful Proxy Binding
      Acknowledgement message.

   o  If the local mobility anchor successfully processes a Proxy
      Binding Update message with the GRE Key option and the downlink
      GRE key included in the GRE Key Identifier field for Initial GRE
      Key exchange as in Section 3.3.1, the local mobility anchor MUST
      include the GRE Key option with the uplink GRE key included in the
      GRE Key Identifier field when responding with a successful Proxy
      Binding Acknowledgement message.

   o  If the GRE tunneling is negotiated and the downlink and uplink GRE
      keys have been exchanged between the mobile access gateway and the
      local mobility anchor for a specific mobility session, the local



Muhanna, et al.          Expires August 28, 2009               [Page 11]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


      mobility anchor MUST use the negotiated downlink GRE key in the
      GRE header of every packet that is destined to the mobile node of
      this specific mobility session over the GRE tunnel to the mobile
      access gateway.

   o  If the received Proxy Binding Update message does not contain the
      GRE Key option, and if the local mobility anchor based on a policy
      check determines that GRE encapsulation and GRE keys are required,
      e.g., overlapping IPv4 private addressing is in use, LMA local
      policy or LMA-MAG peer agreement, the local mobility anchor MUST
      reject the request and send a Proxy Binding Acknowledgement
      message to the mobile access gateway with the status code <GRE KEY
      OPTION REQUIRED> as defined in Section 6.4, indicating that GRE
      encapsulation and GRE keys are required.

   o  If after receiving and successfully processing a Proxy Binding
      Update message with the GRE Key option, the local mobility anchor
      determines based on a policy check that GRE encapsulation and GRE
      keys are not required for this specific binding, e.g., private
      IPv4 addressing is not in use, the LMA SHOULD send a successful
      Proxy Binding Acknowledgement message to the MAG with the status
      code <GRE KEY OPTION NOT REQUIRED>.  In this case, the local
      mobility anchor MUST NOT include the GRE Key option in the Proxy
      Binding Acknowledgement.

   o  If the local mobility anchor successfully processes a de-
      registration Proxy Binding Update message, the LMA follows the
      same de-registration process as described in Proxy Mobile IPv6
      specification [RFC5213] to clean the binding cache entry and all
      associated resources including the downlink and uplink GRE keys.

   o  On receiving a packet from the tunnel with the GRE header, the
      local mobility anchor MUST use the GRE Key in the GRE extension
      header as an additional identifier to determine which mobility
      session this packet belongs to.  The GRE header is removed before
      further processing takes place.


6.  Message Formats

   This section defines an extension to the Mobile IPv6 [RFC3775]
   protocol messages.  The use of GRE Key option for supporting GRE
   tunneling and GRE Key exchange for Proxy Mobile IPv6 is defined in
   this specification.







Muhanna, et al.          Expires August 28, 2009               [Page 12]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


6.1.  GRE Key Option

   A new mobility option, the GRE Key option, is defined for use in the
   Proxy Binding Update and Proxy Binding Acknowledgment messages
   exchanged between the mobile access gateway and the local mobility
   anchor.  This option can also be used in Binding Update and Binding
   Acknowledgment messages exchanged between a mobile node and a home
   agent.

   This option can be used for negotiating GRE encapsulation mode only
   or GRE encapsulation and exchanging the downlink and uplink GRE keys.
   These GRE keys can be used by the peers in all GRE encapsulated
   payload packets for marking that specific mobile node's data traffic.

   The alignment requirement for this option is 4n.


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


                         Figure 2: GRE Key Option

   Type

      <IANA>

   Length

      8-bit unsigned integer indicating the length in octets of the
      option, excluding the type and length fields.  If the Length field
      is set to 2, it indicates that the GRE key Identifier field is not
      being carried in the option.  If the length field is set to a
      value of 6, it means that either the downlink or the uplink GRE
      key is carried.

   Reserved

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






Muhanna, et al.          Expires August 28, 2009               [Page 13]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


   GRE Key Identifier

      32-bit field containing the downlink or the uplink GRE key.  This
      field is present in the GRE Key option only if the GRE keys are
      being exchanged using the Proxy Binding Update and Proxy Binding
      Acknowledgement messages.


6.2.  Proxy Binding Update Message Extension

   This specification extends the Proxy Binding Update message with one
   new flag.  The flag is shown and described below.



       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
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |          Sequence #           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |A|H|L|K|M|R|P|F|T|  Reserved   |           Lifetime            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                  Figure 3: Proxy Binding Update message


   TLV-header Format (T)

      When set, this flag indicates that the mobile access gateway
      requests the use of the TLV-header for encapsulating IPv6-or-IPv4
      in IPv4.  The TLV-header format is described later in this
      specification.  None of the other fields or flags in the Proxy
      Binding Update is modified by this specification.

6.3.  Proxy Binding Acknowledgement Message Extension

   This specification extends the Proxy Binding Acknowledgement message
   with a new flag.  This new flag is shown and described below.











Muhanna, et al.          Expires August 28, 2009               [Page 14]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


       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     |K|R|P|T|   Res |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Sequence #          |           Lifetime            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



              Figure 4: Proxy Binding Acknowledgement Message


   TLV-header Format (T)

      When set, this flag indicates that the sender of the Proxy Binding
      Acknowledgement (LMA) supports tunneling IPv6-or-IPv4 in IPv4
      using TLV-header format.  None of the other fields or flags in the
      Proxy Binding Acknowledgement is modified by this specification.

6.4.  Status Codes

   The following status code values are defined for use in the Binding
   Acknowledgment message when using Proxy Mobile IPv6.


   GRE KEY OPTION NOT REQUIRED (TBD less than 128)

      When the local mobility anchor receives a Proxy Binding Update
      with the GRE Key option while based on a policy check the LMA
      determines that the GRE encapsulation is not required for this
      specific mobility session, the LMA uses this code to indicate to
      the mobile access gateway that the Proxy Binding Update has been
      processed successfully but GRE Encapsulation and GRE Keys are not
      required.

   GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED (TBD less than 128)

      If local mobility anchor receives a Proxy Binding Update with the
      GRE Key option and TLV-header Format (T) flag set, the local
      mobility anchor uses this code to indicate to the mobile access
      gateway that GRE Encapsulation has successfully been negotiated
      but TLV-header format is NOT supported.








Muhanna, et al.          Expires August 28, 2009               [Page 15]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


   GRE KEY OPTION REQUIRED (TBD more than 128)

      When the local mobility anchor receives a Proxy Binding Update
      without the GRE Key option while based on a policy check the local
      mobility anchor determines that GRE encapsulation is required for
      this specific mobility session, the local mobility anchor uses
      this code to reject the Proxy Binding Update and indicate to the
      mobile access gateway that GRE Encapsulation and GRE Keys are
      required.


7.  Data Packets Processing Considerations

   This section describes how the local mobility anchor and mobile
   access gateway encapsulate and decapsulate data packets when GRE
   encapsulation and GRE Keys are used for tunneling mobile nodes data
   traffic between these two mobility nodes.

7.1.  Tunneling Format

   When GRE encapsulation is used, the mobile access gateway is allowed
   to use various tunneling formats depending on the mobile access
   gateway location and the networks's capabilities between the MAG and
   the LMA.  Using vanilla GRE encapsulation, the mobile access gateway
   can tunnel IPv6-or-IPv4 payload packet in IPv6 or in IPv4 following
   the rules in [RFC5213] and [ID-PMIP6-IPv4].

   If UDP-based tunneling is used between the mobile access gateway and
   the local mobility anchor after NAT has been detected in the path
   between the MAG and the LMA while GRE encapsulation is required, the
   TLV-header UDP tunneling format as shown in Figure 5 MUST be used.



         [IPv4 Header]

         [UDP Header]

         [TLV Header]

         [GRE Header]

         [payload - IPv6-or-IPv4 Header]

         Upper Layer protocols


        Figure 5: TLV-header UDP Based Encapsulation Headers Order



Muhanna, et al.          Expires August 28, 2009               [Page 16]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


   When UDP based tunneling format is used between the mobile access
   gateway and the local mobility anchor, the use of the TLV-header is
   negotiated during the Proxy Binding Update/Acknowledgement exchange
   as described in Section 7.3 and Section 7.4.  If the TLV-header
   format is agreed upon between the mobile access gateway and local
   mobility anchor, the LMA expects the TLV-header to follow the UDP
   header as shown in Figure 5.  The TLV header contains the type field,
   the following payload packet header type and its length.  The Type
   field in the TLV-header is always set to a value of 0 to enhance the
   processing of the received packet by ensuring that the receiver can
   differentiate whether what after the UDP header is a TLV-header Type
   field or an IP version field of an IP header.  Hence, the TLV-header
   can carry traffic other than IP as indicated in the Next Header
   field.  The distinction between IP and TLV encapsulation is needed,
   because the Proxy Binding Update (IP Packet) and the data packets
   (GRE packets) can be sent over the same UDP tunnel.


7.2.  TLV-header Tunneling Negotiation

   The mobile access gateway negotiates the format for tunneling payload
   traffic during Proxy Mobile IPv6 registration procedure.  If the
   mobile access gateway is required to use the TLV-header UDP
   encapsulation format, the mobile access gateway MUST set the TLV-
   header Format (T) flag in the Proxy Binding Update message sent to
   the local mobility anchor.  If the local mobility anchor supports the
   TLV-header UDP tunneling format, the LMA SHOULD set the TLV-header
   Format (T) flag in the Proxy Binding Acknowledgement.  Otherwise, the
   TLV-header Format (T) flag is cleared.  The setting of the TLV-header
   Format (T) flag in the Proxy Binding Acknowledgement indicates to the
   mobile access gateway that it MUST use the TLV-header UDP
   encapsulation format for all packets tunneled to the LMA for the
   entire duration the mobile node is attached to the mobile access
   gateway.  The TLV-header UDP tunneling format SHOULD NOT change
   during a Binding Lifetime Extension Proxy Binding Update (re-
   registration) from the same mobile access gateway.

   Any Proxy Binding Update message triggered by a handoff (Section
   5.3.4 of [RFC5213]) may renegotiate the tunneling format.  Therefore,
   in order to avoid interoperability issues, the local mobility anchor
   MUST NOT set the TLV-header Format (T) flag unless it was set in the
   Proxy Binding Update received from the mobile access gateway.

   The TLV-header format is as shown below in Figure 6.







Muhanna, et al.          Expires August 28, 2009               [Page 17]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


       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  |  Res. |  Next Header  |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                        Figure 6: TLV-header Format


   Type

      This field is always 0 (zero) and distinguishes the TLV header
      from the IPv4 and IPv6 headers.

   Res.

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

   Next Header

      8-bit unsigned integer which indicates the protocol number of the
      payload header following this TLV header.  It is set to the
      protocol number as assigned by IANA at the following
      http://www.iana.org/assignments/protocol-numbers. e.g., if an IPv6
      header follows, it should be '41'; '47' if it is a GRE header that
      follows.

   Length

      16-bit unsigned integer indicating the length in octets of the
      payload following this header, excluding the TLV-header itself.


7.3.  Mobile Access Gateway Operation

   When sending a Proxy Binding Update message while the network between
   the mobile access gateway and local mobility anchor is an IPv4-only
   network, the mobile access gateway follows the procedures specified
   in [ID-PMIP6-IPv4] and [ID-DSMIP6] if vanilla UDP encapsulation
   format is used.  However, if GRE encapsulation is required and UDP
   based encapsulation is used, the mobile access gateway MUST set the
   TLV-header Format (T) flag in the Proxy Binding Update and follow
   this specification for GRE encapsulation negotiation.  If the
   received Proxy Binding Acknowledgement is successful and the TLV-
   header Format (T) flag set and the GRE Key option included, the MAG



Muhanna, et al.          Expires August 28, 2009               [Page 18]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


   MUST use the TLV-header UDP based encapsulation format as shown in
   Figure 5.

   If the mobile access gateway receives a Proxy Binding Acknowledgement
   with the status <GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED> in
   response to a Proxy Binding Update with the GRE key option and the
   (T) flag set, the mobile access gateway MUST use GRE encapsulation
   for this mobility session without UDP or TLV headers.  A Proxy
   Binding Acknowledgement message with status <GRE TUNNELING BUT TLV-
   HEADER NOT SUPPORTED> has the (T) flag cleared.  The mobile access
   gateway may resend the Proxy Binding Update to negotiate different
   tunneling options, e.g., using UDP based tunneling without GRE
   encapsulation if possible or de-register the the mobile node mobility
   session.

7.3.1.  Sending and Receiving Data Packets

   When the mobile access gateway is located in an IPv6-enabled or IPv4-
   enabled network, it may be required to use vanilla GRE encapsulation
   for tunneling IPv6 or IPv4 payload data packet to the local mobility
   anchor.  In this case and if the mobile access gateway has
   successfully negotiated GRE encapsulation mode only or GRE
   encapsulation and GRE Keys as described in this specification, the
   mobile access gateway encapsulates or decapsulates IPv6-or-IPv4
   payload packets following the rules described in [RFC5213] and
   [ID-PMIP6-IPv4] while ensuring that the GRE header is present as
   shown in Figure 7.



         [IPv6-or-IPv4 Header]

         [GRE Header]

         [payload - IPv6-or-IPv4 Header]

         Upper Layer protocols


     Figure 7: IPv6-or-IPv4 over IPv4 Using Vanilla GRE Encapsulation


   On the other hand, if the mobile access gateway is located in an
   IPv4-only network where NAT has been detected on the path between the
   MAG and the LMA and successfully negotiated GRE encapsulation and the
   TLV-header format, the mobile access gateway MUST use UDP TLV-header
   tunneling format when sending an IPv6 or IPv4 payload packet to the
   LMA according to the format described in Figure 5.  The source and



Muhanna, et al.          Expires August 28, 2009               [Page 19]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


   the destination of the IPv4 outer header are V4CoA and HA_V4ADDR,
   respectively.  In addition the source and the destination IP
   addresses of the IPv6-or-IPv4 payload data packet are V6/V4HoA and
   V6/V4CN, respectively.


7.4.  Local Mobility Anchor Operation

   When the local mobility anchor receives a Proxy Binding Update
   encapsulated in UDP and containing the IPv4 home address option, it
   needs to follow all the steps in [RFC5213] and [ID-PMIP6-IPv4].  In
   addition, if the TLV-header Format (T) flag is set in the Proxy
   Binding Update, the local mobility anchor needs to determine whether
   it can accept the TLV-header UDP based encapsulation format.  If it
   does, it SHOULD set the TLV-header Format (T) flag in the Proxy
   Binding Acknowledgement.  Otherwise, the LMA MUST NOT set the TLV-
   header Format (T) flag in the Proxy Binding Acknowledgement.


   If the local mobility anchor receives a Proxy Binding Update with the
   GRE Key option and TLV-header Format (T) flag set and based on a
   policy check, the local mobility anchor determines that GRE
   encapsulation is required BUT the LMA does NOT support TLV-header
   tunneling and if Proxy Binding Update has been successfully
   processed, the LMA MUST send a successful Proxy Binding
   Acknowledgement with the status code <GRE TUNNELING BUT TLV-HEADER
   NOT SUPPORTED>.  This way, the local mobility anchor indicates to the
   mobile access gateway that GRE encapsulation has been successfully
   negotiated BUT TLV-header UDP based tunneling format is not
   supported.


   If the local mobility anchor and the mobile access gateway have
   successfully negotiated the TLV-header UDP based tunneling format and
   the GRE encapsulation for a specific mobility session, the local
   mobility anchor processes data packets as described in the following
   subsection.


7.4.1.  Sending and Receiving Data Packets

   The local mobility anchor may use vanilla GRE encapsulation for
   tunneling IPv6 or IPv4 payload data packet to the mobile access
   gateway.  If the LMA has successfully negotiated GRE encapsulation
   with the MAG for a specific mobility session, the local mobility
   anchor encapsulates and decapsulates IPv6-or-IPv4 payload data
   packets following the rules described in [RFC5213] and
   [ID-PMIP6-IPv4] while ensuring that the GRE header is present as



Muhanna, et al.          Expires August 28, 2009               [Page 20]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


   shown in Figure 7.


   In the case when TLV-tunneling format and the GRE encapsulation for a
   specific mobility session have been successfully negotiated between
   the local mobility anchor and the mobile access gateway, the local
   mobility anchor follows the TLV-header UDP based tunneling format and
   headers order as shown in Figure 5 to encapsulate IPv4 or IPv6
   payload packets in IPv4 before sending the IPv4 packet to the mobile
   access gateway.  In this case, the source and the destination of the
   IPv4 outer header are HA_V4ADDR and V4CoA, respectively.  In addition
   the source and the destination IP addresses of the IPv6-or-IPv4
   payload data packet are V6/V4CN and V6/V4HoA, respectively.  On the
   other hand, the local mobility anchor ensures the same TLV-header UDP
   based tunneling format and headers order when it decapsulates
   received IPv4 packets from the mobile access gateway for the same
   mobility session.


7.5.  Mobile Node Operation

   This specification has no impact on IPv4 or IPv6 mobile nodes.


8.  IANA Considerations

   This specification defines a new Mobility Option, the GRE Key Option,
   described in Section 6.1.  This option is carried in the Mobility
   Header.  The type value for this option needs to be assigned from the
   same numbering space as allocated for the other mobility options
   defined in the Mobile IPv6 specification [RFC3775].

   This specification also defines three new Binding Acknowledgement
   status codes as described in Section 6.4 and requests that these
   three codes be allocated with numeric values as specified in
   Section 6.4 from the "Status Codes" registry of the Mobility IPv6
   Parameters located at
   http://www.iana.org/assignments/mobility-parameters.


9.  Security Considerations

   The GRE Key Option, defined in this specification, that can be
   carried in Proxy Binding Update and Proxy Binding Acknowledgement
   messages, reveals the group affiliation of a mobile node identified
   by its NAI or an IP address.  It may help an attacker in targeting
   flows belonging to a specific group.  This vulnerability can be
   prevented, by enabling confidentiality protection on the Proxy



Muhanna, et al.          Expires August 28, 2009               [Page 21]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


   Binding Update and Proxy Binding Acknowledgement messages where the
   presence of the NAI and GRE Key Options establish a mobile node's
   relation to a specific group.  This vulnerability can also be avoided
   by enabling confidentiality protection on all the tunneled data
   packets between the mobile access gateway and the local mobility
   anchor, for hiding all the markings.

   In Proxy Mobile IPv6 [RFC5213], the use of IPsec [RFC4301] for
   protecting a mobile node's data traffic is optional.  Additionally,
   Proxy Mobile IPv6 recommends the use of ESP in tunnel mode when using
   ESP in protecting the mobile node's data traffic.  However, when GRE
   encapsulation is used, both IPsec tunnel mode and transport mode can
   be used to protect the GRE header.  The IPsec traffic selectors will
   contain the protocol number for GRE, and there is currently no
   mechanism to use the GRE key as a traffic selector.


10.  Acknowledgements

   The authors would like to thank Alessio Casati, Barney Barnowski,
   Mark Grayson and Parviz Yegani for their input on the need for this
   option.  The authors would like to thank Charlie Perkins, Curtis
   Provost, Irfan Ali, Jouni Korhonen, Julien Laganier, Kuntal
   Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review
   and comments.


11.  References

11.1.  Normative References

   [ID-DSMIP6]
              Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", draft-ietf-mext-nemo-v4traversal-07 (work in
              progress), December 2008.

   [ID-MCoA]  Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
              "Multiple Care-of Addresses Registration",
              draft-ietf-monami6-multiplecoa-11 (work in progress),
              January 2009.

   [ID-PMIP6-IPv4]
              Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09
              (work in progress), January 2009.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",



Muhanna, et al.          Expires August 28, 2009               [Page 22]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


              BCP 5, RFC 1918, February 1996.

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

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

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998.

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

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

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.


11.2.  Informative References

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.


Authors' Addresses

   Ahmad Muhanna
   Nortel
   2221 Lakeside Blvd.
   Richardson, TX  75082
   USA

   Email: amuhanna@nortel.com











Muhanna, et al.          Expires August 28, 2009               [Page 23]

Internet-Draft       GRE Key Option for Proxy MIPv6        February 2009


   Mohamed Khalil
   Nortel
   2221 Lakeside Blvd.
   Richardson, TX  75082
   USA

   Email: mkhalil@nortel.com


   Sri Gundavelli
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com


   Kent Leung
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: kleung@cisco.com


























Muhanna, et al.          Expires August 28, 2009               [Page 24]


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