GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc5845

Internet Engineering Task Force (IETF) A. Muhanna Request for Comments: 5845 M. Khalil Category: Standards Track Ericsson ISSN: 2070-1721 S. Gundavelli

                                                              K. Leung
                                                                 Cisco
                                                             June 2010
Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6

Abstract

 This specification defines a new mobility option for allowing the
 mobile access gateway and the local mobility anchor to negotiate
 Generic Routing Encapsulation (GRE) encapsulation mode and exchange
 the downlink and uplink GRE keys that 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.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5845.

Copyright Notice

 Copyright (c) 2010 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.  Code Components extracted from this document must

Muhanna, et al. Standards Track [Page 1] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

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

Muhanna, et al. Standards Track [Page 2] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

1. Introduction

 The Proxy Mobile IPv6 specification [RFC5213] and IPv4 Support for
 Proxy Mobile IPv6 [RFC5844] allow the use of IPv6 and IPv4
 encapsulation modes as specified in [RFC2473] and [RFC2003] for the
 tunneled traffic between the local mobility anchor (LMA) and the
 mobile access gateway (MAG).  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 a
 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.
 This specification has no impact on IPv4 or IPv6 mobile nodes.

2. Conventions and 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 the Mobile IPv6 [RFC3775], Proxy Mobile
 IPv6 [RFC5213], and IPv4 Support for Proxy Mobile IPv6 [RFC5844]
 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. Standards Track [Page 3] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

 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 that
    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 that belongs
    to a specific mobility session as described in this specification.
 A Policy Check
    When a local mobility anchor receives an initial, handoff-
    triggered Binding Lifetime Extension, or Binding Lifetime
    Extension Proxy Binding Update for a mobility session, the local
    mobility anchor 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 Key Exchange

 This section describes how GRE encapsulation mode is negotiated and
 the GRE keys are dynamically exchanged using Proxy Mobile IPv6
 protocol [RFC5213] signaling.

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 traffic.  In the case
 when GRE encapsulation mode only is negotiated between the mobile
 access gateway and the local mobility anchor, then no GRE keys are
 used.

Muhanna, et al. Standards Track [Page 4] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

 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
 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 flows belonging to different
 operators.
 The mobile nodes MN-1 and MN-2 are visiting from Operator-A, and the
 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. Standards Track [Page 5] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

 of downlink and uplink GRE keys and save them as part of the mobile
 node's 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
 [RFC5648].

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 local mobility anchor 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 Key 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 the 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 mobile access gateway 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

Muhanna, et al. Standards Track [Page 6] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

 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.
 After the local mobility anchor successfully processes the initial
 Proxy Binding Update and accepts the GRE encapsulation request and
 the downlink GRE key based on a policy check, the local mobility
 anchor 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 mobile access gateway.

3.3.2. GRE Key Exchange during Binding Re-Registration

 If the local mobility anchor has successfully negotiated and
 exchanged the initial GRE keys with the mobile access gateway for a
 specific mobile node's mobility session, the local mobility anchor
 MUST maintain the same negotiated uplink GRE key for the lifetime of
 that mobility session.  However, for administrative reasons, e.g.,
 local mobility anchor reboot, the local mobility anchor MAY change
 the uplink GRE key for the mobility session.  In that case, some
 packet loss may be experienced.
 If the mobile access gateway has successfully negotiated and
 exchanged the initial GRE keys with the local mobility anchor for a
 specific mobile node's mobility session, the mobile access gateway
 MUST include the GRE Key option with the downlink GRE key in the
 Proxy Binding Update that is used to request a Binding Lifetime
 Extension.  In this case, if the local mobility anchor successfully
 processes the Proxy Binding Update message, the local mobility anchor
 MUST return the same uplink GRE key that was exchanged with the
 mobile access gateway in the last successful Proxy Binding Update for
 the same mobility session in the GRE Key option in a successful Proxy
 Binding Acknowledgement message.
 However, during inter-MAG handoff and if the new mobile access
 gateway determines, based on, e.g., private IPv4 address support, the
 mobile access gateway 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 that is used to request an after-handoff Binding
 Lifetime Extension.  In this case, the new mobile access gateway may
 either pick a new downlink GRE key or use the downlink GRE key that
 was used by the previous mobile access gateway for the same binding.
 For the new mobile access gateway to know the downlink GRE key used
 by the previous mobile access gateway, it may require transfer of

Muhanna, et al. Standards Track [Page 7] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

 context from the previous mobile access gateway to the new mobile
 access gateway during a handoff.  Such mechanisms are out of scope
 for this specification.
 If the local mobility anchor successfully processes a handoff-
 triggered Binding Lifetime Extension Proxy Binding Update message
 that contains a GRE Key option with a downlink GRE key included, the
 local mobility anchor MUST return the same uplink GRE key that was
 exchanged with the previous mobile access gateway for the same
 mobility session in the GRE Key option in a successful Proxy Binding
 Acknowledgement.
 If the local mobility anchor receives a handoff-triggered Binding
 Lifetime Extension Proxy Binding Update message without the GRE Key
 option for a Binding Cache entry (BCE) that is using GRE keys and GRE
 encapsulation, the local mobility anchor makes a policy check
 regarding GRE encapsulation and GRE key exchange.  If, according to
 the policy check, GRE encapsulation and GRE key exchange are
 required, the local mobility anchor MUST reject the Proxy Binding
 Update by sending a Proxy Binding Acknowledgement message with the
 Status field set to GRE_KEY_OPTION_REQUIRED as defined in
 Section 6.4.  Otherwise, the local mobility anchor SHOULD accept the
 Proxy Binding Update, and if it is processed successfully, the local
 mobility anchor MUST return a successful Proxy Binding
 Acknowledgement without including the GRE Key option.

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 four new
 additional fields.
 o  A flag (GRE-encapsulation-enabled) is used for 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 mobile access gateway and communicated
    to the local mobility anchor in the GRE Key option in the Proxy
    Binding Update message.

Muhanna, et al. Standards Track [Page 8] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

 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 local mobility anchor as
    specified in this document.
 o  A flag indicating whether UDP-based TLV-header format
    (Section 7.2) is enabled for the mobile node's traffic.  This flag
    is TRUE only when UDP tunneling as in [RFC5844] and GRE
    encapsulation as in this specification are both enabled for this
    mobility session.

4.2. Operational Summary

 o  If the mobile access gateway determines that GRE encapsulation
    mode only is required, the mobile access gateway 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 mobile access gateway determines that GRE encapsulation and
    GRE keys are required, the mobile access gateway 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 Acknowledgement message
    with the GRE Key option with the GRE Key Identifier field omitted,
    the mobile access gateway MUST update the mobile node's Binding
    Update List entry described in Section 4.1 by only setting the
    GRE-encapsulation-enabled flag.
 o  After receiving a successful Proxy Binding Acknowledgement 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 fields in the mobile node's Binding Update List entry
    described in Section 4.1.  Additionally, the mobile access gateway
    MUST use the assigned uplink GRE Key for tunneling all the traffic
    that belongs to this mobile node BUL entry and that originated
    from the mobile node before forwarding the tunneled traffic to the
    local mobility anchor.
 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

Muhanna, et al. Standards Track [Page 9] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

    GRE Key option, then the mobile access gateway MUST consider that
    the local mobility anchor does not support the 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 local mobility anchor.
 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 GRE encapsulation and GRE keys are required, the
    mobile access gateway SHOULD resend the Proxy Binding Update
    message with the GRE Key option.  If the mobile access gateway
    does not support the GRE Key option, it 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
    the status code GRE_KEY_OPTION_NOT_REQUIRED, the mobile access
    gateway MUST consider that GRE encapsulation and GRE keys are not
    required for this specific mobility session.  The mobile access
    gateway follows procedures in the 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 local mobility anchor for this
    mobility session.
 o  If the mobile access gateway has successfully negotiated GRE
    encapsulation and exchanged the GRE keys with the local mobility
    anchor for a specific mobility session, the mobile access gateway
    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 to which
    mobility session this packet belongs.  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's BCE.  This requires
 the BCE described in Section 5.1 of the Proxy Mobile IPv6

Muhanna, et al. Standards Track [Page 10] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

 specification [RFC5213] to be extended.  To support this
 specification, the BCE must be extended with the following four
 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 mobile access gateway 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 local mobility anchor and used
    in the GRE encapsulation header of the tunneled payload packet
    from the mobile access gateway to the local mobility anchor.
 o  A flag indicating whether UDP-based TLV-header format
    (Section 7.2) is enabled for the mobile node's traffic.  This flag
    is TRUE only when UDP tunneling as in [RFC5844] and GRE
    encapsulation as in this specification are both enabled for this
    mobility session.

5.2. Operational Summary

 o  If the 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
    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.

Muhanna, et al. Standards Track [Page 11] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

 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, a local
    mobility anchor 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.
    This indicates 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 local mobility anchor SHOULD
    send a successful Proxy Binding Acknowledgement message to the
    mobile access gateway 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 local mobility
    anchor follows the same de-registration process as described in
    the 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 to which mobility
    session this packet belongs.  The GRE header is removed before
    further processing takes place.

6. Message Formats

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

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 Acknowledgement messages
 exchanged between the mobile access gateway and the local mobility
 anchor.  This option can be used for negotiating GRE encapsulation
 mode only or GRE encapsulation and exchanging the downlink and uplink

Muhanna, et al. Standards Track [Page 12] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

 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
    33
 Length
    An 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.
 GRE Key Identifier
    A 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 as
 defined in [RFC5213] with the new TLV-header format (T) flag.  The
 new (T) flag is described below and shown as part of the Proxy
 Binding Update message as in Figure 3.

Muhanna, et al. Standards Track [Page 13] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

     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
    packets in IPv4.  The TLV-header format is described in
    Section 7.2.  None of the other fields or flags in the Proxy
    Binding Update are modified by this specification.

6.3. Proxy Binding Acknowledgement Message Extension

 This specification extends the Proxy Binding Acknowledgement message
 as defined in [RFC5213] with the new TLV-header format (T) flag.  The
 new (T) flag is described below and shown as part of the Proxy
 Binding Acknowledgement message as in Figure 4.
     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, the LMA, supports tunneling IPv6-or-IPv4 in IPv4
    using TLV-header format.  None of the other fields or flags in the
    Proxy Binding Acknowledgement are modified by this specification.

6.4. Status Codes

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

Muhanna, et al. Standards Track [Page 14] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

 GRE_KEY_OPTION_NOT_REQUIRED (2)
    When the local mobility anchor receives a Proxy Binding Update
    with the GRE Key option, and based on a policy check it determines
    that GRE encapsulation is not required for this specific mobility
    session, it 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 (3)
    If the 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 been successfully negotiated
    but TLV-header format is NOT supported.
 GRE_KEY_OPTION_REQUIRED (163)
    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 and 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 the mobile node's
 data traffic between these two mobile 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 network capabilities between the mobile
 access gateway and the local mobility anchor.  Using GRE
 encapsulation, as described in [RFC2784] and [RFC2890], the mobile
 access gateway can tunnel the IPv6-or-IPv4 payload packet in IPv6 or
 in IPv4 following the rules in [RFC5213] and [RFC5844].
 If UDP-based tunneling is used in conjunction with GRE encapsulation
 between the mobile access gateway and the local mobility anchor, the
 TLV-header UDP tunneling format as shown in Figure 5 MUST be used.

Muhanna, et al. Standards Track [Page 15] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

       [IPv4 Header]
       [UDP Header]
       [TLV Header]
       [GRE Header]
       [Payload - IPv6 or IPv4 Header]
       Upper Layer protocols
       Figure 5: TLV-Header UDP-Based Encapsulation Header Order
 When a 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 Sections 7.3 and 7.4.  If the TLV-header format is
 agreed upon between the mobile access gateway and local mobility
 anchor, the local mobility anchor 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 came 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.
 When processing a UDP packet with the TLV-header format, if the
 receiving node found that the payload packet length as calculated
 from the UDP header length field is different than its length as
 calculated from the TLV-header length field, the receiving node MUST
 discard the received IP packet.

7.2. TLV-Header Tunneling Negotiation

 The mobile access gateway negotiates the format for tunneling payload
 traffic during the 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 local mobility anchor SHOULD set
 the TLV-header format (T) flag in the Proxy Binding Acknowledgement.

Muhanna, et al. Standards Track [Page 16] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

 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 local
 mobility anchor 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.
     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
    An 8-bit unsigned integer that indicates the protocol number of
    the payload header following this TLV header.  It is set to the
    protocol number as assigned by IANA in the "Assigned Internet
    Protocol Numbers" registry.  For example, if an IPv6 header
    follows, it should be '41'; if a GRE header follows, it should be
    '47'.
 Length
    A 16-bit unsigned integer indicating the length in octets of the
    payload following this header, excluding the TLV header itself.

Muhanna, et al. Standards Track [Page 17] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

7.3. Mobile Access Gateway Operation

 When sending a Proxy Binding Update message over an IPv4 transport
 network, the mobile access gateway follows the procedures specified
 in [RFC5844] for using IPv4-UDP encapsulation mode.  However, when
 using GRE header in conjunction with IPv4-UDP encapsulation mode is
 required, 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 is
 set and the GRE Key option included, the mobile access gateway MUST
 update the mobile node's Binding Update List entry described in
 Section 4.1 by setting the UDP-based TLV-header format (T) flag.  In
 this case, the mobile access gateway 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
 without UDP encapsulation.  If the mobile access gateway is allowed
 to use GRE encapsulation without UDP tunneling, the mobile access
 gateway MUST update the mobile node's Binding Update List entry
 described in Section 4.1 by setting the GRE-encapsulation-enabled
 flag and the uplink and downlink GRE key fields.  In this case, the
 mobile access gateway MUST set the UDP-based TLV-header format (T)
 flag to FALSE.  A Proxy Binding Acknowledgement message with the
 status code GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED has the (T)
 flag cleared.  Alternatively, 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 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 GRE encapsulation for
 tunneling IPv6 or IPv4 data packets 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 [RFC5844] while ensuring that
 the GRE header is present as shown in Figure 7.

Muhanna, et al. Standards Track [Page 18] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

       [IPv6 or IPv4 Header]
       [GRE Header]
       [Payload - IPv6 or IPv4 Header]
       Upper Layer protocols
       Figure 7: IPv6-or-IPv4 over IPv4 Using 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
 mobile access gateway and the local mobility anchor 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 local mobility anchor according
 to the format described in Figure 5.  The source and the destination
 of the IPv4 outer header are mobile node IPv4 Proxy Care-of Address,
 IPv4-Proxy-CoA, and the IPv4 local mobility anchor address, IPv4-
 LMAA, respectively.  In addition, the source and the destination IP
 addresses of the IPv6-or-IPv4 payload data packet are the mobile
 node's IPv6-or-IPv4 home address, IPv6/IPv4-MN-HoA, and the IPv6-or-
 IPv4 corresponding node's address, IPv6/IPv4-CN-Addr, 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 Request
 option ([RFC5844]), it needs to follow all the steps in [RFC5213] and
 [RFC5844].  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
 local mobility anchor MUST NOT set the TLV-header format (T) flag in
 the Proxy Binding Acknowledgement.
 If the local mobility anchor (LMA) receives a Proxy Binding Update
 with the GRE Key option and TLV-header format (T) flag set and, based
 on a policy check, the LMA determines that GRE encapsulation is
 required and the LMA supports TLV-header tunneling and the LMA sent a
 successful Proxy Binding Acknowledgement with the TLV-header format
 (T) flag set, the LMA MUST update the mobile node's Binding Cache
 entry described in Section 5.1 by setting the GRE-encapsulation-
 enabled flag and update the uplink and downlink GRE key fields.  In
 addition, the LMA MUST set the UDP-based TLV-header format flag.

Muhanna, et al. Standards Track [Page 19] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

 If the LMA receives a Proxy Binding Update with the GRE Key option
 and TLV-header format (T) flag set and, based on a policy check, the
 LMA determines that GRE encapsulation is required BUT the LMA does
 NOT support TLV-header tunneling and if the 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 LMA
 indicates to the mobile access gateway that GRE encapsulation has
 been successfully negotiated BUT TLV-header UDP-based tunneling
 format is not supported.  In this case, the LMA MUST update the
 mobile node's BCE described in Section 5.1 by setting the GRE
 encapsulation enabled flag and update the uplink and downlink GRE key
 fields.  In this case, the LMA MUST set the UDP-based TLV-header
 format flag to FALSE.
 If the local mobility anchor and the mobile access gateway have
 successfully negotiated the TLV-header UDP-based tunneling format and
 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 GRE encapsulation for tunneling an
 IPv6 or IPv4 data packet to the mobile access gateway.  If the local
 mobility anchor has successfully negotiated GRE encapsulation with
 the mobile access gateway 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 [RFC5844]
 while ensuring that the GRE header is present as shown in Figure 7.
 In the case when TLV-tunneling format and 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
 header 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 IPv4-LMAA and IPv4-Proxy-CoA, respectively.  In
 addition, the source and the destination IP addresses of the IPv6-or-
 IPv4 payload data packet are IPv6/IPv4-CN-Addr and IPv6/IPv4-MN-HoA,
 respectively.  On the other hand, the local mobility anchor ensures
 the same TLV-header UDP-based tunneling format and header order when
 it decapsulates received IPv4 packets from the mobile access gateway
 for the same mobility session.

Muhanna, et al. Standards Track [Page 20] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

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 has been 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 IANA has allocated the
 numeric values as specified in Section 6.4 from the "Status Codes"
 registry of the Mobility IPv6 Parameters.

9. Security Considerations

 The GRE Key option, defined in this specification, when carried in
 Proxy Binding Update and Proxy Binding Acknowledgement messages,
 reveals the group affiliation of a mobile node identified by its
 Network Access Identifier (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 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 Encapsulating Security
 Payload (ESP) [RFC4303] in tunnel mode when using ESP for 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.

Muhanna, et al. Standards Track [Page 21] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

11. References

11.1. Normative References

 [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
            E. Lear, "Address Allocation for Private Internets",
            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.
 [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
            Mobile IPv6", RFC 5844, May 2010.

11.2. Informative References

 [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
            Internet Protocol", RFC 4301, December 2005.
 [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
            RFC 4303, December 2005.
 [RFC5648]  Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
            and K. Nagami, "Multiple Care-of Addresses Registration",
            RFC 5648, October 2009.

Muhanna, et al. Standards Track [Page 22] RFC 5845 GRE Key Option for Proxy MIPv6 June 2010

Authors' Addresses

 Ahmad Muhanna
 Ericsson, Inc.
 2201 Lakeside Blvd.
 Richardson, TX  75082
 USA
 EMail: ahmad.muhanna@ericsson.com
 Mohamed Khalil
 Ericsson, Inc.
 6300 Legacy Dr.
 Plano, TX  75024
 USA
 EMail: Mohamed.khalil@ericsson.com
 Sri Gundavelli
 Cisco
 170 West Tasman Drive
 San Jose, CA  95134
 USA
 EMail: sgundave@cisco.com
 Kent Leung
 Cisco
 170 West Tasman Drive
 San Jose, CA  95134
 USA
 EMail: kleung@cisco.com

Muhanna, et al. Standards Track [Page 23]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5845.txt · Last modified: 2010/06/07 02:33 (external edit)