draft-ietf-netlmm-grekey-option-09.txt   rfc5845.txt 
Network Working Group A. Muhanna Internet Engineering Task Force (IETF) A. Muhanna
Internet-Draft M. Khalil Request for Comments: 5845 M. Khalil
Intended status: Standards Track Nortel Category: Standards Track Ericsson
Expires: November 7, 2009 S. Gundavelli ISSN: 2070-1721 S. Gundavelli
K. Leung K. Leung
Cisco Systems Cisco
May 6, 2009 June 2010
GRE Key Option for Proxy Mobile IPv6
draft-ietf-netlmm-grekey-option-09.txt
Status of this Memo Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6
This Internet-Draft is submitted to IETF in full conformance with the Abstract
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This specification defines a new mobility option for allowing the
Task Force (IETF), its areas, and its working groups. Note that mobile access gateway and the local mobility anchor to negotiate
other groups may also distribute working documents as Internet- Generic Routing Encapsulation (GRE) encapsulation mode and exchange
Drafts. 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.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
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 This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (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.
This Internet-Draft will expire on November 7, 2009. 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 Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This specification defines a new Mobility Option for allowing the described in the Simplified BSD License.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . . . 4 3. GRE Encapsulation and Key Exchange . . . . . . . . . . . . . . 4
3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 4 3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 4
3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 6 3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 6
3.3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . 6 3.3. GRE Encapsulation and Key Exchange . . . . . . . . . . . . 6
3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 6 3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 6
3.3.2. GRE Key Exchange During Binding Re-registration . . . 7 3.3.2. GRE Key Exchange during Binding Re-Registration . . . 7
4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 8 4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 8
4.1. Extensions to the Conceptual Data Structure . . . . . . . 8 4.1. Extensions to the Conceptual Data Structure . . . . . . . 8
4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 9 4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 9
5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 10 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 10
5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 10 5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 10
5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 11 5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 11
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 12 6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Proxy Binding Update Message Extension . . . . . . . . . . 13 6.2. Proxy Binding Update Message Extension . . . . . . . . . . 13
6.3. Proxy Binding Acknowledgement Message Extension . . . . . 14 6.3. Proxy Binding Acknowledgement Message Extension . . . . . 14
6.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 14
7. Data Packets Processing Considerations . . . . . . . . . . . . 15 7. Data Packets Processing Considerations . . . . . . . . . . . . 15
7.1. Tunneling Format . . . . . . . . . . . . . . . . . . . . . 16 7.1. Tunneling Format . . . . . . . . . . . . . . . . . . . . . 15
7.2. TLV-header Tunneling Negotiation . . . . . . . . . . . . . 17 7.2. TLV-Header Tunneling Negotiation . . . . . . . . . . . . . 16
7.3. Mobile Access Gateway Operation . . . . . . . . . . . . . 18 7.3. Mobile Access Gateway Operation . . . . . . . . . . . . . 18
7.3.1. Sending and Receiving Data Packets . . . . . . . . . . 19 7.3.1. Sending and Receiving Data Packets . . . . . . . . . . 18
7.4. Local Mobility Anchor Operation . . . . . . . . . . . . . 20 7.4. Local Mobility Anchor Operation . . . . . . . . . . . . . 19
7.4.1. Sending and Receiving Data Packets . . . . . . . . . . 21 7.4.1. Sending and Receiving Data Packets . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile IPv6 The Proxy Mobile IPv6 specification [RFC5213] and IPv4 Support for
support for IPv4 [ID-PMIP6-IPv4] allow the use of IPv6 and IPv4 Proxy Mobile IPv6 [RFC5844] allow the use of IPv6 and IPv4
encapsulation modes as specified in [RFC2473] and [RFC2003] for the encapsulation modes as specified in [RFC2473] and [RFC2003] for the
tunneled traffic between the local mobility anchor (LMA) and the tunneled traffic between the local mobility anchor (LMA) and the
mobile access gateway (MAG). There are scenarios where these mobile access gateway (MAG). There are scenarios where these
encapsulation modes are not sufficient to uniquely identify the encapsulation modes are not sufficient to uniquely identify the
destination of packets of a specific mobility session. Thus, there destination of packets of a specific mobility session. Thus, there
is a need for an encapsulation mode with richer semantics. The is a need for an encapsulation mode with richer semantics. The
Generic Routing Encapsulation (GRE) [RFC2784] and the Key extension Generic Routing Encapsulation (GRE) [RFC2784], and the Key extension
as defined in [RFC2890], has the required semantics to allow such as defined in [RFC2890], has the required semantics to allow such a
distinction for use in Proxy Mobile IPv6. distinction for use in Proxy Mobile IPv6.
This specification defines the GRE Key option to be used for the This specification defines the GRE Key option to be used for the
negotiation of GRE encapsulation mode and exchange of the uplink and negotiation of GRE encapsulation mode and exchange of the uplink and
downlink GRE keys. The negotiated downlink and uplink GRE keys can downlink GRE keys. The negotiated downlink and uplink GRE keys can
be used for marking the downlink and uplink traffic for a specific be used for marking the downlink and uplink traffic for a specific
mobility session. In addition, this specification enables the mobile mobility session. In addition, this specification enables the mobile
access gateway and the local mobility anchor to negotiate the use of access gateway and the local mobility anchor to negotiate the use of
GRE encapsulation mode without exchanging the GRE keys. GRE encapsulation mode without exchanging the GRE keys.
This specification has no impact on IPv4 or IPv6 mobile nodes. This specification has no impact on IPv4 or IPv6 mobile nodes.
2. Conventions & Terminology 2. Conventions and Terminology
2.1. Conventions 2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
specification are to be interpreted as described in RFC 2119 specification are to be interpreted as described in RFC 2119
[RFC2119]. [RFC2119].
2.2. Terminology 2.2. Terminology
All the general mobility related terminology and abbreviations are to All the general mobility-related terminology and abbreviations are to
be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile be interpreted as defined in the Mobile IPv6 [RFC3775], Proxy Mobile
IPv6 [RFC5213] specifications. The following terms are used in this IPv6 [RFC5213], and IPv4 Support for Proxy Mobile IPv6 [RFC5844]
specification. specifications. The following terms are used in this specification.
Downlink Traffic Downlink Traffic
The traffic in the tunnel between the local mobility anchor and The traffic in the tunnel between the local mobility anchor and
the mobile access gateway, heading towards the mobile access the mobile access gateway, heading towards the mobile access
gateway and tunneled at the local mobility anchor. This traffic gateway and tunneled at the local mobility anchor. This traffic
is also called forward direction traffic. is also called forward direction traffic.
Uplink Traffic Uplink Traffic
The traffic in the tunnel between the mobile access gateway and The traffic in the tunnel between the mobile access gateway and
the local mobility anchor, heading towards the local mobility the local mobility anchor, heading towards the local mobility
anchor and tunneled at the mobile access gateway. This traffic is anchor and tunneled at the mobile access gateway. This traffic is
also called reverse direction traffic. also called reverse direction traffic.
Downlink GRE Key Downlink GRE Key
The GRE key is assigned by the mobile access gateway and used by The GRE key is assigned by the mobile access gateway and used by
the local mobility anchor to mark the downlink traffic which the local mobility anchor to mark the downlink traffic that
belongs to a specific mobility session as described in this belongs to a specific mobility session as described in this
specification. specification.
Uplink GRE Key Uplink GRE Key
The GRE key is assigned by the local mobility anchor and used by The GRE key is assigned by the local mobility anchor and used by
the mobile access gateway to mark the uplink traffic which belongs the mobile access gateway to mark the uplink traffic that belongs
to a specific mobility session as described in this specification. to a specific mobility session as described in this specification.
A Policy Check A Policy Check
When local mobility anchor receives an initial, handoff-triggered When a local mobility anchor receives an initial, handoff-
Binding Lifetime Extension, or Binding Lifetime Extension Proxy triggered Binding Lifetime Extension, or Binding Lifetime
Binding Update for a mobility session, the local mobility anchor Extension Proxy Binding Update for a mobility session, the local
determines if the GRE encapsulation mode only or GRE encapsulation mobility anchor determines if the GRE encapsulation mode only or
and GRE keys are required based on a policy check. This policy GRE encapsulation and GRE keys are required based on a policy
could be a per MAG-LMA pair, a per-LMA local policy, a per-MN check. This policy could be a per-MAG-LMA pair, a per-LMA local
policy, or the combination of any of them. policy, a per-MN policy, or the combination of any of them.
3. GRE Encapsulation and Keys Exchange 3. GRE Encapsulation and Key Exchange
This section describes how GRE encapsulation mode is negotiated and This section describes how GRE encapsulation mode is negotiated and
the GRE keys are dynamically exchanged while using Proxy Mobile IPv6 the GRE keys are dynamically exchanged using Proxy Mobile IPv6
protocol [RFC5213] signaling. protocol [RFC5213] signaling.
3.1. GRE Encapsulation Overview 3.1. GRE Encapsulation Overview
Using the GRE Key option defined in this specification, the mobile Using the GRE Key option defined in this specification, the mobile
access gateway and the local mobility anchor can negotiate GRE access gateway and the local mobility anchor can negotiate GRE
encapsulation mode only or GRE encapsulation mode and exchange the encapsulation mode only or GRE encapsulation mode and exchange the
GRE keys for marking the downlink and uplink traffics. In the case GRE keys for marking the downlink and uplink traffic. In the case
when GRE encapsulation mode only is negotiated between the mobile when GRE encapsulation mode only is negotiated between the mobile
access gateway and the local mobility anchor, then no GRE keys are access gateway and the local mobility anchor, then no GRE keys are
used. used.
However, once the GRE keys have been exchanged between the mobile However, once the GRE keys have been exchanged between the mobile
access gateway and the local mobility anchor as per this access gateway and the local mobility anchor as per this
specification, the mobile access gateway will use the uplink GRE key specification, the mobile access gateway will use the uplink GRE key
that is assigned by the local mobility anchor in the GRE header of that is assigned by the local mobility anchor in the GRE header of
the uplink payload packet. Similarly, the local mobility anchor will the uplink payload packet. Similarly, the local mobility anchor will
use the downlink GRE key as negotiated with the mobile access gateway use the downlink GRE key as negotiated with the mobile access gateway
skipping to change at page 5, line 44 skipping to change at page 5, line 46
| | | |
| 10.x.0.0/16| | 10.x.0.0/16|
+------------+ +------------+
Figure 1: GRE Tunneling for IPv4 Private Address Space Overlapping Figure 1: GRE Tunneling for IPv4 Private Address Space Overlapping
Figure 1 illustrates a local mobility anchor providing mobility Figure 1 illustrates a local mobility anchor providing mobility
service to mobile nodes that are from different operators and are service to mobile nodes that are from different operators and are
assigned IPv4 addresses from overlapping private address space. In assigned IPv4 addresses from overlapping private address space. In
this scenario, the mobile access gateway and the local mobility this scenario, the mobile access gateway and the local mobility
anchor must be able to distinguish the flows belonging to a given anchor must be able to distinguish flows belonging to different
operator from the flows belonging to some other operator. operators.
The mobile nodes, MN-1 and MN-2 are visiting from Operator-A, and 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 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 access gateway and the local mobility anchor exchange a specific pair
of downlink and uplink GRE keys and save them as part of the mobile 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 node's binding to be used for identifying the flows belonging to each
mobile node. mobile node.
The LMA and the MAG will be able to distinguish 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 flow(s) based on the GRE key present in the GRE header of the
tunneled payload packet, and route them accordingly. However, the tunneled payload packet, and route them accordingly. However, the
GRE keys as in this specification apply to the individual mobility GRE keys, as in this specification, apply to the individual mobility
binding updated by the Proxy Binding Update but not to all bindings binding updated by the Proxy Binding Update but not to all bindings
that the mobile may have registered following procedures described in that the mobile may have registered following procedures described in
[ID-MCoA]. [RFC5648].
3.2. GRE Encapsulation Mode Only 3.2. GRE Encapsulation Mode Only
In order for the mobile access gateway to request GRE encapsulation In order for the mobile access gateway to request GRE encapsulation
mode only without exchanging the GRE keys, the mobile access gateway mode only without exchanging the GRE keys, the mobile access gateway
MUST include the GRE Key option but omit the GRE Key Identifier field MUST include the GRE Key option but omit the GRE Key Identifier field
in the Proxy Binding Update. in the Proxy Binding Update.
If the local mobility anchor supports GRE encapsulation and the If the local mobility anchor supports GRE encapsulation and the
received Proxy Binding Update contains the GRE Key option but the GRE received Proxy Binding Update contains the GRE Key option but the GRE
skipping to change at page 6, line 41 skipping to change at page 6, line 36
requesting GRE encapsulation without exchanging the GRE keys requesting GRE encapsulation without exchanging the GRE keys
dynamically. If the Proxy Binding Update processing is successful, dynamically. If the Proxy Binding Update processing is successful,
the local mobility anchor sends a successful Proxy Binding the local mobility anchor sends a successful Proxy Binding
Acknowledgement message with the GRE Key option but the GRE Key Acknowledgement message with the GRE Key option but the GRE Key
Identifier field is omitted. Identifier field is omitted.
When the mobile access gateway and the local mobility anchor When the mobile access gateway and the local mobility anchor
successfully negotiate the GRE encapsulation mode only, then no GRE successfully negotiate the GRE encapsulation mode only, then no GRE
keys are used. keys are used.
3.3. GRE Encapsulation and Keys Exchange 3.3. GRE Encapsulation and Key Exchange
The following subsections describe how the mobile access gateway and The following subsections describe how the mobile access gateway and
the local mobility anchor negotiate GRE encapsulation and exchange the local mobility anchor negotiate GRE encapsulation and exchange
downlink and uplink GRE keys using proxy mobile IPv6 registration downlink and uplink GRE keys using the Proxy Mobile IPv6 registration
procedure. procedure.
3.3.1. Initial GRE Key Exchange 3.3.1. Initial GRE Key Exchange
When the mobile access gateway determines, based on, e.g., private When the mobile access gateway determines, based on, e.g., private
IPv4 address support [RFC1918], the mobile access gateway local IPv4 address support [RFC1918], the mobile access gateway local
policy, or the MAG-LMA peer agreement, that GRE encapsulation is policy, or the MAG-LMA peer agreement, that GRE encapsulation is
needed and GRE keys are required, the mobile access gateway MUST needed and GRE keys are required, the mobile access gateway MUST
include the GRE Key option in the initial Proxy Binding Update include the GRE Key option in the initial Proxy Binding Update
message sent to the local mobility anchor. The mobile access gateway message sent to the local mobility anchor. The mobile access gateway
MUST include the downlink GRE key in the GRE Key Identifier field of MUST include the downlink GRE key in the GRE Key Identifier field of
the GRE Key option. the GRE Key option.
After the local mobility anchor successfully processes the initial After the local mobility anchor successfully processes the initial
Proxy Binding Update and accepts the GRE encapsulation request and Proxy Binding Update and accepts the GRE encapsulation request and
the downlink GRE key based on a policy check, the local mobility 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 anchor MUST include the GRE Key option with the uplink GRE key in the
GRE Key Identifier field in a successful Proxy Binding GRE Key Identifier field in a successful Proxy Binding
Acknowledgement and send it to the mobile access gateway. Acknowledgement and send it to the mobile access gateway.
3.3.2. GRE Key Exchange During Binding Re-registration 3.3.2. GRE Key Exchange during Binding Re-Registration
If the local mobility anchor has successfully negotiated and If the local mobility anchor has successfully negotiated and
exchanged the initial GRE keys with the mobile access gateway for a exchanged the initial GRE keys with the mobile access gateway for a
specific mobile node binding, the local mobility anchor MUST maintain specific mobile node's mobility session, the local mobility anchor
the same negotiated uplink GRE key for the lifetime of the mobility MUST maintain the same negotiated uplink GRE key for the lifetime of
session. However, for administrative reasons, e.g., local mobility that mobility session. However, for administrative reasons, e.g.,
anchor reboot, the local mobility anchor MAY change the uplink GRE local mobility anchor reboot, the local mobility anchor MAY change
key for the mobility session. In that case, some packet loss may be the uplink GRE key for the mobility session. In that case, some
experienced. packet loss may be experienced.
If the mobile access gateway has successfully negotiated and If the mobile access gateway has successfully negotiated and
exchanged the initial GRE keys with the local mobility anchor for a exchanged the initial GRE keys with the local mobility anchor for a
specific mobile node binding, the mobile access gateway MUST include specific mobile node's mobility session, the mobile access gateway
the GRE Key option with the downlink GRE key in the Proxy Binding MUST include the GRE Key option with the downlink GRE key in the
Update which is used for requesting a Binding Lifetime Extension. In Proxy Binding Update that is used to request a Binding Lifetime
this case, if the local mobility anchor successfully processes the Extension. In this case, if the local mobility anchor successfully
Proxy Binding Update message, the local mobility anchor MUST return processes the Proxy Binding Update message, the local mobility anchor
the same uplink GRE key that was exchanged with the mobile access MUST return the same uplink GRE key that was exchanged with the
gateway in the last successful Proxy Binding Update for the same mobile access gateway in the last successful Proxy Binding Update for
mobility session in the GRE key option in a successful Proxy Binding the same mobility session in the GRE Key option in a successful Proxy
Acknowledgement message. Binding Acknowledgement message.
However, during inter-MAG handoff and if the new mobile access However, during inter-MAG handoff and if the new mobile access
gateway determines, based on, e.g., private IPv4 address support, the gateway determines, based on, e.g., private IPv4 address support, the
mobile access gateway local policy, the MAG-LMA peer agreement, or an mobile access gateway local policy, the MAG-LMA peer agreement, or an
indication during the handoff process, that GRE encapsulation and GRE indication during the handoff process, that GRE encapsulation and GRE
keys exchange are required, the new mobile access gateway MUST keys exchange are required, the new mobile access gateway MUST
include the GRE key option with the downlink GRE key in the Proxy include the GRE Key option with the downlink GRE key in the Proxy
Binding Update which is used for requesting an after handoff Binding Binding Update that is used to request an after-handoff Binding
Lifetime extension. In this case, the new mobile access gateway may 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 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. 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 For the new mobile access gateway to know the downlink GRE key used
by the previous mobile access gateway, it may require transfer of by the previous mobile access gateway, it may require transfer of
context from the previous mobile access gateway to the new mobile context from the previous mobile access gateway to the new mobile
access gateway during a handoff. Such mechanisms are out-of-scope access gateway during a handoff. Such mechanisms are out of scope
for this specification. for this specification.
If the local mobility anchor successfully processes a handoff- If the local mobility anchor successfully processes a handoff-
triggered Binding Lifetime Extension Proxy Binding Update message triggered Binding Lifetime Extension Proxy Binding Update message
which contains a GRE key option with a downlink GRE key included, the 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 local mobility anchor MUST return the same uplink GRE key that was
exchanged with the previous mobile access gateway for the same exchanged with the previous mobile access gateway for the same
mobility session in the GRE key option in a successful Proxy Binding mobility session in the GRE Key option in a successful Proxy Binding
Acknowledgement. Acknowledgement.
If the local mobility anchor receives a handoff-triggered Binding If the local mobility anchor receives a handoff-triggered Binding
Lifetime Extension Proxy Binding Update message without the GRE key Lifetime Extension Proxy Binding Update message without the GRE Key
option for a Binding Cache Entry (BCE) that is using GRE keys and GRE option for a Binding Cache entry (BCE) that is using GRE keys and GRE
encapsulation, the local mobility anchor makes a policy check encapsulation, the local mobility anchor makes a policy check
regarding GRE encapsulation and GRE keys exchange. If, according to regarding GRE encapsulation and GRE key exchange. If, according to
the policy check, GRE encapsulation and GRE Keys exchange are the policy check, GRE encapsulation and GRE key exchange are
required, the local mobility anchor MUST reject the Proxy Binding required, the local mobility anchor MUST reject the Proxy Binding
Update by sending a Proxy Binding Acknowledgement message with the Update by sending a Proxy Binding Acknowledgement message with the
status field is set to <GRE KEY OPTION REQUIRED> as defined in Status field set to GRE_KEY_OPTION_REQUIRED as defined in
Section 6.4. Otherwise, the local mobility anchor SHOULD accept the Section 6.4. Otherwise, the local mobility anchor SHOULD accept the
Proxy Binding Update and if it is processed successfully, the local Proxy Binding Update, and if it is processed successfully, the local
mobility anchor MUST return a successful Proxy Binding mobility anchor MUST return a successful Proxy Binding
Acknowledgement without including the GRE Key option. Acknowledgement without including the GRE Key option.
4. Mobile Access Gateway Considerations 4. Mobile Access Gateway Considerations
4.1. Extensions to the Conceptual Data Structure 4.1. Extensions to the Conceptual Data Structure
Every mobile access gateway maintains a Binding Update List (BUL) Every mobile access gateway maintains a Binding Update List (BUL)
entry for each currently attached mobile node, as explained in entry for each currently attached mobile node, as explained in
Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213]. To Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213]. To
support this specification, the conceptual Binding Update List entry support this specification, the conceptual Binding Update List entry
data structure must be extended with the following three new data structure must be extended with the following four new
additional fields. additional fields.
o A flag indicating whether GRE encapsulation is enabled for the o A flag (GRE-encapsulation-enabled) is used for indicating whether
mobile node's traffic. GRE encapsulation is enabled for the mobile node's traffic.
o The downlink GRE key used in the GRE encapsulation header of the o The downlink GRE key used in the GRE encapsulation header of the
tunneled payload packet from the local mobility anchor to the tunneled payload packet from the local mobility anchor to the
mobile access gateway that is destined to the mobile node. This mobile access gateway that is destined to the mobile node. This
GRE key is generated by the mobile access gateway and communicated GRE key is generated by the mobile access gateway and communicated
to the local mobility anchor in the GRE Key option in the Proxy to the local mobility anchor in the GRE Key option in the Proxy
Binding Update message. Binding Update message.
o The uplink GRE key used in the GRE encapsulation header of the o The uplink GRE key used in the GRE encapsulation header of the
tunneled payload packet from the mobile access gateway to the tunneled payload packet from the mobile access gateway to the
local mobility anchor that is originating from the mobile node. local mobility anchor that is originating from the mobile node.
This GRE key is obtained from the GRE Key Identifier field of the This GRE key is obtained from the GRE Key Identifier field of the
GRE Key option present in the received Proxy Binding GRE Key option present in the received Proxy Binding
Acknowledgement message sent by the local mobility anchor as Acknowledgement message sent by the local mobility anchor as
specified in this specification. specified in this document.
o A flag indicating whether UDP based TLV-Header format Section 7.2 o A flag indicating whether UDP-based TLV-header format
is enabled for the mobile node's traffic. This flag is TRUE only (Section 7.2) is enabled for the mobile node's traffic. This flag
when UDP tunneling as in [ID-PMIP6-IPv4] and GRE Encapsulation as is TRUE only when UDP tunneling as in [RFC5844] and GRE
in this specification are both enabled for this mobility session. encapsulation as in this specification are both enabled for this
mobility session.
4.2. Operational Summary 4.2. Operational Summary
o If the mobile access gateway determines that GRE encapsulation o If the mobile access gateway determines that GRE encapsulation
mode only is required, the mobile access gateway MUST include the mode only is required, the mobile access gateway MUST include the
GRE Key option but omit the GRE Key Identifier field in the Proxy GRE Key option but omit the GRE Key Identifier field in the Proxy
Binding Update message that is sent to the local mobility anchor. Binding Update message that is sent to the local mobility anchor.
o If the mobile access gateway determines that GRE encapsulation and o If the mobile access gateway determines that GRE encapsulation and
GRE keys are required, the mobile access gateway MUST include the GRE keys are required, the mobile access gateway MUST include the
GRE Key option with the downlink GRE key in the GRE Key Identifier 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 field in the Proxy Binding Update message that is sent to the
local mobility anchor. local mobility anchor.
o After receiving a successful Proxy Binding Acknowledgment message o After receiving a successful Proxy Binding Acknowledgement message
with the GRE Key option with the GRE Key Identifier field omitted, with the GRE Key option with the GRE Key Identifier field omitted,
the mobile access gateway MUST update the mobile node Binding the mobile access gateway MUST update the mobile node's Binding
Update List entry described in Section 4.1 by only setting the GRE Update List entry described in Section 4.1 by only setting the
encapsulation enabled flag. GRE-encapsulation-enabled flag.
o After receiving a successful Proxy Binding Acknowledgment message o After receiving a successful Proxy Binding Acknowledgement message
with the GRE Key option and the uplink GRE key included in the GRE with the GRE Key option and the uplink GRE key included in the GRE
Key Identifier field, the mobile access gateway MUST update the Key Identifier field, the mobile access gateway MUST update the
related three fields in the mobile node Binding Update List entry related fields in the mobile node's Binding Update List entry
described in Section 4.1. Additionally, the mobile access gateway described in Section 4.1. Additionally, the mobile access gateway
MUST use the assigned uplink GRE Key for tunneling all the traffic MUST use the assigned uplink GRE Key for tunneling all the traffic
that belong to this mobile node BUL entry and is originated from that belongs to this mobile node BUL entry and that originated
the mobile node before forwarding the tunneled traffic to the from the mobile node before forwarding the tunneled traffic to the
local mobility anchor. local mobility anchor.
o If the mobile access gateway includes the GRE Key option in the o If the mobile access gateway includes the GRE Key option in the
Proxy Binding Update for a specific mobile node and the local Proxy Binding Update for a specific mobile node and the local
mobility anchor accepts the Proxy Binding Update by sending a mobility anchor accepts the Proxy Binding Update by sending a
Proxy Binding Acknowledgement with a success status code (less Proxy Binding Acknowledgement with a success status code (less
than 128) other than <GRE KEY OPTION NOT REQUIRED>, but without than 128) other than GRE_KEY_OPTION_NOT_REQUIRED, but without the
the GRE Key option, then the mobile access gateway MUST consider GRE Key option, then the mobile access gateway MUST consider that
that the local mobility anchor does not support GRE Key option as the local mobility anchor does not support the GRE Key option as
per this specification. The mobile access gateway SHOULD NOT per this specification. The mobile access gateway SHOULD NOT
include the GRE Key option in any subsequent Proxy Binding Update include the GRE Key option in any subsequent Proxy Binding Update
message that is sent to that local mobility anchor. message that is sent to that local mobility anchor.
o If the mobile access gateway sent a Proxy Binding Update message o If the mobile access gateway sent a Proxy Binding Update message
without the GRE Key option, but the received Proxy Binding without the GRE Key option, but the received Proxy Binding
Acknowledgement has the Status Code <GRE KEY OPTION REQUIRED>, Acknowledgement has the status code GRE_KEY_OPTION_REQUIRED,
indicating that the GRE encapsulation and GRE key is required, the indicating that GRE encapsulation and GRE keys are required, the
mobile access gateway SHOULD resend the Proxy Binding Update mobile access gateway SHOULD resend the Proxy Binding Update
message with the GRE Key option. If the mobile access gateway message with the GRE Key option. If the mobile access gateway
does not support the GRE Key option, it MAY log the event and does not support the GRE Key option, it MAY log the event and
possibly raise an alarm to indicate a possible misconfiguration. possibly raise an alarm to indicate a possible misconfiguration.
o If the mobile access gateway sent a Proxy Binding Update message o If the mobile access gateway sent a Proxy Binding Update message
with the GRE Key option and the downlink GRE key included and with the GRE Key option and the downlink GRE key included and
received a successful Proxy Binding Acknowledgement message with a received a successful Proxy Binding Acknowledgement message with
status code <GRE KEY OPTION NOT REQUIRED>, the mobile access the status code GRE_KEY_OPTION_NOT_REQUIRED, the mobile access
gateway MUST consider that GRE encapsulation and GRE keys is not gateway MUST consider that GRE encapsulation and GRE keys are not
required for this specific mobility session. The mobile access required for this specific mobility session. The mobile access
gateway follows procedures in Proxy Mobile IPv6 specification gateway follows procedures in the Proxy Mobile IPv6 specification
[RFC5213] for the handling of uplink and downlink traffic and MUST [RFC5213] for the handling of uplink and downlink traffic and MUST
NOT include the GRE Key option in any subsequent Proxy Binding NOT include the GRE Key option in any subsequent Proxy Binding
Update message that is sent to the local mobility anchor for this Update message that is sent to the local mobility anchor for this
mobility session. mobility session.
o If the mobile access gateway has successfully negotiated GRE o If the mobile access gateway has successfully negotiated GRE
encapsulation and exchanged the GRE keys with the local mobility encapsulation and exchanged the GRE keys with the local mobility
anchor for a specific mobility session, the mobile access gateway anchor for a specific mobility session, the mobile access gateway
SHOULD NOT include the GRE Key option in the de-registration Proxy SHOULD NOT include the GRE Key option in the de-registration Proxy
Binding Update. Binding Update.
o On receiving a packet from the tunnel with the GRE header, the 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 mobile access gateway MUST use the GRE key present in the GRE
extension header as an additional identifier to determine which extension header as an additional identifier to determine to which
mobility session this packet belongs to. The GRE header is mobility session this packet belongs. The GRE header is removed
removed before further processing takes place. before further processing takes place.
5. Local Mobility Anchor Considerations 5. Local Mobility Anchor Considerations
5.1. Extensions to the Binding Cache Entry 5.1. Extensions to the Binding Cache Entry
When the local mobility anchor and the mobile access gateway When the local mobility anchor and the mobile access gateway
successfully negotiate GRE encapsulation and exchange downlink and successfully negotiate GRE encapsulation and exchange downlink and
uplink GRE keys, the local mobility anchor MUST maintain the downlink 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 and uplink GRE keys as part of the mobile node's BCE. This requires
that the BCE described in section 5.1 of the Proxy Mobile IPv6 the BCE described in Section 5.1 of the Proxy Mobile IPv6
specification [RFC5213] to be extended. To support this specification [RFC5213] to be extended. To support this
specification, the BCE must be extended with the following three specification, the BCE must be extended with the following four
additional fields. additional fields.
o A flag indicating whether GRE encapsulation is enabled for the o A flag indicating whether GRE encapsulation is enabled for the
mobile node's traffic flows. mobile node's traffic flows.
o The downlink GRE Key, assigned by the mobile access gateway and o The downlink GRE key, assigned by the mobile access gateway and
used in the GRE encapsulation header of the tunneled payload used in the GRE encapsulation header of the tunneled payload
packet from the local mobility anchor to the mobile access packet from the local mobility anchor to the mobile access
gateway. gateway.
o The Uplink GRE Key, assigned by the local mobility anchor and used o The uplink GRE key, assigned by the local mobility anchor and used
in the GRE encapsulation header of the tunneled payload packet in the GRE encapsulation header of the tunneled payload packet
from the mobile access gateway to the local mobility anchor. from the mobile access gateway to the local mobility anchor.
o A flag indicating whether UDP based TLV-Header format Section 7.2 o A flag indicating whether UDP-based TLV-header format
is enabled for the mobile node's traffic. This flag is TRUE only (Section 7.2) is enabled for the mobile node's traffic. This flag
when UDP tunneling as in [ID-PMIP6-IPv4] and GRE Encapsulation as is TRUE only when UDP tunneling as in [RFC5844] and GRE
in this specification are both enabled for this mobility session. encapsulation as in this specification are both enabled for this
mobility session.
5.2. Operational Summary 5.2. Operational Summary
o If local mobility anchor successfully processes a Proxy Binding o If the local mobility anchor successfully processes a Proxy
Update message with the GRE Key option but the GRE Key Identifier Binding Update message with the GRE Key option, but the GRE Key
field is omitted for Initial GRE Key exchange, the local mobility Identifier field is omitted for initial GRE key exchange, the
anchor MUST include the GRE Key option but omit the GRE Key local mobility anchor MUST include the GRE Key option but omit the
Identifier field when responding with a successful Proxy Binding GRE Key Identifier field when responding with a successful Proxy
Acknowledgement message. Binding Acknowledgement message.
o If the local mobility anchor successfully processes a Proxy o If the local mobility anchor successfully processes a Proxy
Binding Update message with the GRE Key option and the downlink Binding Update message with the GRE Key option and the downlink
GRE key included in the GRE Key Identifier field for Initial GRE 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 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 include the GRE Key option with the uplink GRE key included in the
GRE Key Identifier field when responding with a successful Proxy GRE Key Identifier field when responding with a successful Proxy
Binding Acknowledgement message. Binding Acknowledgement message.
o If the GRE tunneling is negotiated and the downlink and uplink GRE o If the GRE tunneling is negotiated and the downlink and uplink GRE
keys have been exchanged between the mobile access gateway and the keys have been exchanged between the mobile access gateway and the
local mobility anchor for a specific mobility session, the local local mobility anchor for a specific mobility session, the local
mobility anchor MUST use the negotiated downlink GRE key in the mobility anchor MUST use the negotiated downlink GRE key in the
GRE header of every packet that is destined to the mobile node of GRE header of every packet that is destined to the mobile node of
this specific mobility session over the GRE tunnel to the mobile this specific mobility session over the GRE tunnel to the mobile
access gateway. access gateway.
o If the received Proxy Binding Update message does not contain the 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 GRE Key option, and if the local mobility anchor based on a policy
check determines that GRE encapsulation and GRE keys are required, check determines that GRE encapsulation and GRE keys are required,
e.g., overlapping IPv4 private addressing is in use, local e.g., overlapping IPv4 private addressing is in use, a local
mobility anchor local policy or LMA-MAG peer agreement, the local mobility anchor local policy, or LMA-MAG peer agreement, the local
mobility anchor MUST reject the request and send a Proxy Binding mobility anchor MUST reject the request and send a Proxy Binding
Acknowledgement message to the mobile access gateway with the Acknowledgement message to the mobile access gateway with the
status code <GRE KEY OPTION REQUIRED> as defined in Section 6.4, status code GRE_KEY_OPTION_REQUIRED as defined in Section 6.4.
indicating that GRE encapsulation and GRE keys are required. This indicates that GRE encapsulation and GRE keys are required.
o If after receiving and successfully processing a Proxy Binding o If, after receiving and successfully processing a Proxy Binding
Update message with the GRE Key option, the local mobility anchor Update message with the GRE Key option, the local mobility anchor
determines based on a policy check that GRE encapsulation and GRE determines, based on a policy check, that GRE encapsulation and
keys are not required for this specific binding, e.g., private GRE keys are not required for this specific binding, e.g., private
IPv4 addressing is not in use, the local mobility anchor SHOULD IPv4 addressing is not in use, the local mobility anchor SHOULD
send a successful Proxy Binding Acknowledgement message to the send a successful Proxy Binding Acknowledgement message to the
mobile access gateway with the status code <GRE KEY OPTION NOT mobile access gateway with the status code
REQUIRED>. In this case, the local mobility anchor MUST NOT GRE_KEY_OPTION_NOT_REQUIRED. In this case, the local mobility
include the GRE Key option in the Proxy Binding Acknowledgement. anchor MUST NOT include the GRE Key option in the Proxy Binding
Acknowledgement.
o If the local mobility anchor successfully processes a de- o If the local mobility anchor successfully processes a de-
registration Proxy Binding Update message, the local mobility registration Proxy Binding Update message, the local mobility
anchor follows the same de-registration process as described in anchor follows the same de-registration process as described in
Proxy Mobile IPv6 specification [RFC5213] to clean the binding the Proxy Mobile IPv6 specification [RFC5213] to clean the Binding
cache entry and all associated resources including the downlink Cache entry and all associated resources including the downlink
and uplink GRE keys. and uplink GRE keys.
o On receiving a packet from the tunnel with the GRE header, the 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 local mobility anchor MUST use the GRE key in the GRE extension
header as an additional identifier to determine which mobility header as an additional identifier to determine to which mobility
session this packet belongs to. The GRE header is removed before session this packet belongs. The GRE header is removed before
further processing takes place. further processing takes place.
6. Message Formats 6. Message Formats
This section defines an extension to the Mobile IPv6 [RFC3775] This section defines an extension to the Mobile IPv6 protocol
protocol messages. The use of GRE Key option for supporting GRE [RFC3775] messages. The use of the GRE Key option for supporting GRE
tunneling and GRE Key exchange for Proxy Mobile IPv6 is defined in tunneling and GRE key exchange for Proxy Mobile IPv6 is defined in
this specification. this specification.
6.1. GRE Key Option 6.1. GRE Key Option
A new mobility option, the GRE Key option, is defined for use in the A new mobility option, the GRE Key option, is defined for use in the
Proxy Binding Update and Proxy Binding Acknowledgment messages Proxy Binding Update and Proxy Binding Acknowledgement messages
exchanged between the mobile access gateway and the local mobility exchanged between the mobile access gateway and the local mobility
anchor. This option can be used for negotiating GRE encapsulation anchor. This option can be used for negotiating GRE encapsulation
mode only or GRE encapsulation and exchanging the downlink and uplink 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 GRE keys. These GRE keys can be used by the peers in all GRE
encapsulated payload packets for marking that specific mobile node's encapsulated payload packets for marking that specific mobile node's
data traffic. data traffic.
The alignment requirement for this option is 4n. The alignment requirement for this option is 4n.
0 1 2 3 0 1 2 3
skipping to change at page 13, line 22 skipping to change at page 13, line 22
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key Identifier | | GRE Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: GRE Key Option Figure 2: GRE Key Option
Type Type
<IANA> 33
Length Length
8-bit unsigned integer indicating the length in octets of the An 8-bit unsigned integer indicating the length in octets of the
option, excluding the type and length fields. If the Length field 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 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 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 value of 6, it means that either the downlink or the uplink GRE
key is carried. key is carried.
Reserved Reserved
These fields are unused. They MUST be initialized to zero by the These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
GRE Key Identifier GRE Key Identifier
32-bit field containing the downlink or the uplink GRE key. This A 32-bit field containing the downlink or the uplink GRE key.
field is present in the GRE Key option only if the GRE keys are This field is present in the GRE Key option only if the GRE keys
being exchanged using the Proxy Binding Update and Proxy Binding are being exchanged using the Proxy Binding Update and Proxy
Acknowledgement messages. Binding Acknowledgement messages.
6.2. Proxy Binding Update Message Extension 6.2. Proxy Binding Update Message Extension
This specification extends the Proxy Binding Update message as This specification extends the Proxy Binding Update message as
defined in [RFC5213] with the new TLV-Header format (T) flag. The 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 new (T) flag is described below and shown as part of the Proxy
Binding Update message as in Figure 3. Binding Update message as in Figure 3.
0 1 2 3 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 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 # | | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T| Reserved | Lifetime | |A|H|L|K|M|R|P|F|T| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Proxy Binding Update message Figure 3: Proxy Binding Update Message
TLV-header Format (T) TLV-header format (T)
When set, this flag indicates that the mobile access gateway When set, this flag indicates that the mobile access gateway
requests the use of the TLV-header for encapsulating IPv6-or-IPv4 requests the use of the TLV header for encapsulating IPv6 or IPv4
in IPv4. The TLV-header format is described later in this packets in IPv4. The TLV-header format is described in
specification. None of the other fields or flags in the Proxy Section 7.2. None of the other fields or flags in the Proxy
Binding Update is modified by this specification. Binding Update are modified by this specification.
6.3. Proxy Binding Acknowledgement Message Extension 6.3. Proxy Binding Acknowledgement Message Extension
This specification extends the Proxy Binding Acknowledgement message This specification extends the Proxy Binding Acknowledgement message
as defined in [RFC5213] with the new TLV-Header format (T) flag. The 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 new (T) flag is described below and shown as part of the Proxy
Binding Acknowledgement message as in Figure 4. Binding Acknowledgement message as in Figure 4.
0 1 2 3 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 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 | | Status |K|R|P|T| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime | | Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Proxy Binding Acknowledgement Message Figure 4: Proxy Binding Acknowledgement Message
TLV-header Format (T) TLV-header format (T)
When set, this flag indicates that the sender of the Proxy Binding When set, this flag indicates that the sender of the Proxy Binding
Acknowledgement (LMA) supports tunneling IPv6-or-IPv4 in IPv4 Acknowledgement, the LMA, supports tunneling IPv6-or-IPv4 in IPv4
using TLV-header format. None of the other fields or flags in the using TLV-header format. None of the other fields or flags in the
Proxy Binding Acknowledgement is modified by this specification. Proxy Binding Acknowledgement are modified by this specification.
6.4. Status Codes 6.4. Status Codes
The following status code values are defined for use in the Binding The following status code values are defined for use in the Binding
Acknowledgment message when using Proxy Mobile IPv6. Acknowledgement message when using Proxy Mobile IPv6.
GRE KEY OPTION NOT REQUIRED (TBD less than 128) GRE_KEY_OPTION_NOT_REQUIRED (2)
When the local mobility anchor receives a Proxy Binding Update When the local mobility anchor receives a Proxy Binding Update
with the GRE Key option while based on a policy check the local with the GRE Key option, and based on a policy check it determines
mobility anchor determines that the GRE encapsulation is not that GRE encapsulation is not required for this specific mobility
required for this specific mobility session, the local mobility session, it uses this code to indicate to the mobile access
anchor uses this code to indicate to the mobile access gateway gateway that the Proxy Binding Update has been processed
that the Proxy Binding Update has been processed successfully but successfully but GRE encapsulation and GRE keys are not required.
GRE Encapsulation and GRE Keys are not required.
GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED (TBD less than 128) GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED (3)
If local mobility anchor receives a Proxy Binding Update with the If the local mobility anchor receives a Proxy Binding Update with
GRE Key option and TLV-header Format (T) flag set, the local the GRE Key option and TLV-header format (T) flag set, the local
mobility anchor uses this code to indicate to the mobile access mobility anchor uses this code to indicate to the mobile access
gateway that GRE Encapsulation has successfully been negotiated gateway that GRE encapsulation has been successfully negotiated
but TLV-header format is NOT supported. but TLV-header format is NOT supported.
GRE KEY OPTION REQUIRED (TBD more than 128) GRE_KEY_OPTION_REQUIRED (163)
When the local mobility anchor receives a Proxy Binding Update When the local mobility anchor receives a Proxy Binding Update
without the GRE Key option while based on a policy check the local without the GRE Key option while based on a policy check, the
mobility anchor determines that GRE encapsulation is required for local mobility anchor determines that GRE encapsulation is
this specific mobility session, the local mobility anchor uses required for this specific mobility session and uses this code to
this code to reject the Proxy Binding Update and indicate to the reject the Proxy Binding Update and indicate to the mobile access
mobile access gateway that GRE Encapsulation and GRE Keys are gateway that GRE encapsulation and GRE keys are required.
required.
7. Data Packets Processing Considerations 7. Data Packets Processing Considerations
This section describes how the local mobility anchor and mobile This section describes how the local mobility anchor and mobile
access gateway encapsulate and decapsulate data packets when GRE access gateway encapsulate and decapsulate data packets when GRE
encapsulation and GRE Keys are used for tunneling mobile nodes data encapsulation and GRE keys are used for tunneling the mobile node's
traffic between these two mobility nodes. data traffic between these two mobile nodes.
7.1. Tunneling Format 7.1. Tunneling Format
When GRE encapsulation is used, the mobile access gateway is allowed When GRE encapsulation is used, the mobile access gateway is allowed
to use various tunneling formats depending on the mobile access to use various tunneling formats depending on the mobile access
gateway location and the networks's capabilities between the mobile gateway location and the network capabilities between the mobile
access gateway and the local mobility anchor. Using GRE access gateway and the local mobility anchor. Using GRE
encapsulation, as described in [RFC2784] and [RFC2890], the mobile encapsulation, as described in [RFC2784] and [RFC2890], the mobile
access gateway can tunnel IPv6-or-IPv4 payload packet in IPv6 or in access gateway can tunnel the IPv6-or-IPv4 payload packet in IPv6 or
IPv4 following the rules in [RFC5213] and [ID-PMIP6-IPv4]. in IPv4 following the rules in [RFC5213] and [RFC5844].
If UDP-based tunneling is used between the mobile access gateway and If UDP-based tunneling is used in conjunction with GRE encapsulation
the local mobility anchor after NAT has been detected in the path between the mobile access gateway and the local mobility anchor, the
between the mobile access gateway and the local mobility anchor while TLV-header UDP tunneling format as shown in Figure 5 MUST be used.
GRE encapsulation is required, the TLV-header UDP tunneling format as
shown in Figure 5 MUST be used.
[IPv4 Header] [IPv4 Header]
[UDP Header] [UDP Header]
[TLV Header] [TLV Header]
[GRE Header] [GRE Header]
[payload - IPv6-or-IPv4 Header] [Payload - IPv6 or IPv4 Header]
Upper Layer protocols Upper Layer protocols
Figure 5: TLV-header UDP Based Encapsulation Headers Order Figure 5: TLV-Header UDP-Based Encapsulation Header Order
When UDP based tunneling format is used between the mobile access 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 gateway and the local mobility anchor, the use of the TLV header is
negotiated during the Proxy Binding Update/Acknowledgement exchange negotiated during the Proxy Binding Update/Acknowledgement exchange
as described in Section 7.3 and Section 7.4. If the TLV-header as described in Sections 7.3 and 7.4. If the TLV-header format is
format is agreed upon between the mobile access gateway and local agreed upon between the mobile access gateway and local mobility
mobility anchor, the local mobility anchor expects the TLV-header to anchor, the local mobility anchor expects the TLV header to follow
follow the UDP header as shown in Figure 5. The TLV header contains the UDP header as shown in Figure 5. The TLV header contains the
the type field, the following payload packet header type and its Type field, the following payload packet header type, and its length.
length. The Type field in the TLV-header is always set to a value of The Type field in the TLV header is always set to a value of 0 to
0 to enhance the processing of the received packet by ensuring that enhance the processing of the received packet by ensuring that the
the receiver can differentiate whether what after the UDP header is a receiver can differentiate whether what came after the UDP header is
TLV-header Type field or an IP version field of an IP header. Hence, a TLV-header Type field or an IP version field of an IP header.
the TLV-header can carry traffic other than IP as indicated in the Hence, the TLV header can carry traffic other than IP as indicated in
Next Header field. The distinction between IP and TLV encapsulation the Next Header field. The distinction between IP and TLV
is needed, because the Proxy Binding Update (IP Packet) and the data encapsulation is needed, because the Proxy Binding Update (IP packet)
packets (GRE packets) can be sent over the same UDP tunnel. 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 When processing a UDP packet with the TLV-header format, if the
receiving node found that the payload packet length as calculated receiving node found that the payload packet length as calculated
from the UDP header length field is different than its length as from the UDP header length field is different than its length as
calculated from the TLV-header length field, the receiving node MUST calculated from the TLV-header length field, the receiving node MUST
discard the received IP packet. discard the received IP packet.
7.2. TLV-header Tunneling Negotiation 7.2. TLV-Header Tunneling Negotiation
The mobile access gateway negotiates the format for tunneling payload The mobile access gateway negotiates the format for tunneling payload
traffic during Proxy Mobile IPv6 registration procedure. If the traffic during the Proxy Mobile IPv6 registration procedure. If the
mobile access gateway is required to use the TLV-header UDP mobile access gateway is required to use the TLV-header UDP
encapsulation format, the mobile access gateway MUST set the TLV- encapsulation format, the mobile access gateway MUST set the TLV-
header Format (T) flag in the Proxy Binding Update message sent to header format (T) flag in the Proxy Binding Update message sent to
the local mobility anchor. If the local mobility anchor supports the the local mobility anchor. If the local mobility anchor supports the
TLV-header UDP tunneling format, the local mobility anchor SHOULD set TLV-header UDP tunneling format, the local mobility anchor SHOULD set
the TLV-header Format (T) flag in the Proxy Binding Acknowledgement. the TLV-header format (T) flag in the Proxy Binding Acknowledgement.
Otherwise, the TLV-header Format (T) flag is cleared. The setting of
Otherwise, the TLV-header format (T) flag is cleared. The setting of
the TLV-header Format (T) flag in the Proxy Binding Acknowledgement the TLV-header Format (T) flag in the Proxy Binding Acknowledgement
indicates to the mobile access gateway that it MUST use the TLV- indicates to the mobile access gateway that it MUST use the TLV-
header UDP encapsulation format for all packets tunneled to the local header UDP encapsulation format for all packets tunneled to the local
mobility anchor for the entire duration the mobile node is attached mobility anchor for the entire duration the mobile node is attached
to the mobile access gateway. The TLV-header UDP tunneling format to the mobile access gateway. The TLV-header UDP tunneling format
SHOULD NOT change during a Binding Lifetime Extension Proxy Binding SHOULD NOT change during a Binding Lifetime Extension Proxy Binding
Update (re-registration) from the same mobile access gateway. Update (re-registration) from the same mobile access gateway.
Any Proxy Binding Update message triggered by a handoff (Section Any Proxy Binding Update message triggered by a handoff (Section
5.3.4 of [RFC5213]) may renegotiate the tunneling format. Therefore, 5.3.4 of [RFC5213]) may renegotiate the tunneling format. Therefore,
in order to avoid interoperability issues, the local mobility anchor 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 MUST NOT set the TLV-header format (T) flag unless it was set in the
Proxy Binding Update received from the mobile access gateway. Proxy Binding Update received from the mobile access gateway.
The TLV-header format is as shown below in Figure 6. The TLV-header format is as shown below in Figure 6.
0 1 2 3 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 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 | | Type | Res. | Next Header | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TLV-header Format Figure 6: TLV-Header Format
Type Type
This field is always 0 (zero) and distinguishes the TLV header This field is always 0 (zero) and distinguishes the TLV header
from the IPv4 and IPv6 headers. from the IPv4 and IPv6 headers.
Res. Res.
These fields are Reserved and unused. They MUST be initialized to These fields are Reserved and unused. They MUST be initialized to
zero by the sender and MUST be ignored by the receiver. zero by the sender and MUST be ignored by the receiver.
Next Header Next Header
8-bit unsigned integer which indicates the protocol number of the An 8-bit unsigned integer that indicates the protocol number of
payload header following this TLV header. It is set to the the payload header following this TLV header. It is set to the
protocol number as assigned by IANA at the following protocol number as assigned by IANA in the "Assigned Internet
http://www.iana.org/assignments/protocol-numbers. e.g., if an IPv6 Protocol Numbers" registry. For example, if an IPv6 header
header follows, it should be '41'; '47' if it is a GRE header that follows, it should be '41'; if a GRE header follows, it should be
follows. '47'.
Length Length
16-bit unsigned integer indicating the length in octets of the A 16-bit unsigned integer indicating the length in octets of the
payload following this header, excluding the TLV-header itself. payload following this header, excluding the TLV header itself.
7.3. Mobile Access Gateway Operation 7.3. Mobile Access Gateway Operation
When sending a Proxy Binding Update message while the network between When sending a Proxy Binding Update message over an IPv4 transport
the mobile access gateway and local mobility anchor is an IPv4-only
network, the mobile access gateway follows the procedures specified network, the mobile access gateway follows the procedures specified
in [ID-PMIP6-IPv4] if regular UDP encapsulation format is used. in [RFC5844] for using IPv4-UDP encapsulation mode. However, when
However, if GRE encapsulation is required and UDP based encapsulation using GRE header in conjunction with IPv4-UDP encapsulation mode is
is used, the mobile access gateway MUST set the TLV-header Format (T) required, the mobile access gateway MUST set the TLV-header format
flag in the Proxy Binding Update and follow this specification for (T) flag in the Proxy Binding Update and follow this specification
GRE encapsulation negotiation. If the received Proxy Binding for GRE encapsulation negotiation. If the received Proxy Binding
Acknowledgement is successful and the TLV-header Format (T) flag set Acknowledgement is successful and the TLV-header format (T) flag is
and the GRE Key option included, the mobile access gateway MUST set and the GRE Key option included, the mobile access gateway MUST
update the mobile node Binding Update List entry described in update the mobile node's Binding Update List entry described in
Section 4.1 by setting the UDP based TLV-Header format flag. In this Section 4.1 by setting the UDP-based TLV-header format (T) flag. In
case, the mobile access gateway MUST use the TLV-header UDP based this case, the mobile access gateway MUST use the TLV-header UDP-
encapsulation format as shown in Figure 5. based encapsulation format as shown in Figure 5.
If the mobile access gateway receives a Proxy Binding Acknowledgement If the mobile access gateway receives a Proxy Binding Acknowledgement
with the status <GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED> in with the status GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED in
response to a Proxy Binding Update with the GRE key option and the response to a Proxy Binding Update with the GRE Key option and the
(T) flag set, the mobile access gateway MUST use GRE encapsulation (T) flag set, the mobile access gateway MUST use GRE encapsulation
without UDP encapsulation. If the mobile access gateway is allowed without UDP encapsulation. If the mobile access gateway is allowed
to use GRE encapsulation without UDP tunneling, e.g., the mobile to use GRE encapsulation without UDP tunneling, the mobile access
access gateway is NOT behind a NAT, the mobile access gateway MUST gateway MUST update the mobile node's Binding Update List entry
update the mobile node Binding Update List entry described in described in Section 4.1 by setting the GRE-encapsulation-enabled
Section 4.1 by setting the GRE encapsulation enabled flag and the flag and the uplink and downlink GRE key fields. In this case, the
uplink and downlink GRE key fields. In this case, the mobile access mobile access gateway MUST set the UDP-based TLV-header format (T)
gateway MUST set the UDP based TLV-Header format flag to FALSE. A flag to FALSE. A Proxy Binding Acknowledgement message with the
Proxy Binding Acknowledgement message with status <GRE TUNNELING BUT status code GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED has the (T)
TLV-HEADER NOT SUPPORTED> has the (T) flag cleared. Alternatively, flag cleared. Alternatively, the mobile access gateway may resend
the mobile access gateway may resend the Proxy Binding Update to the Proxy Binding Update to negotiate different tunneling options,
negotiate different tunneling options, e.g., using UDP based e.g., using UDP-based tunneling without GRE encapsulation if possible
tunneling without GRE encapsulation if possible or de-register the or de-register the mobile node mobility session.
mobile node mobility session.
7.3.1. Sending and Receiving Data Packets 7.3.1. Sending and Receiving Data Packets
When the mobile access gateway is located in an IPv6-enabled or IPv4- When the mobile access gateway is located in an IPv6-enabled or IPv4-
enabled network, it may be required to use GRE encapsulation for enabled network, it may be required to use GRE encapsulation for
tunneling IPv6 or IPv4 payload data packet to the local mobility tunneling IPv6 or IPv4 data packets to the local mobility anchor. In
anchor. In this case and if the mobile access gateway has this case, and if the mobile access gateway has successfully
successfully negotiated GRE encapsulation mode only or GRE negotiated GRE encapsulation mode only or GRE encapsulation and GRE
encapsulation and GRE Keys as described in this specification, the keys as described in this specification, the mobile access gateway
mobile access gateway encapsulates or decapsulates IPv6-or-IPv4 encapsulates or decapsulates IPv6-or-IPv4 payload packets following
payload packets following the rules described in [RFC5213] and the rules described in [RFC5213] and [RFC5844] while ensuring that
[ID-PMIP6-IPv4] while ensuring that the GRE header is present as the GRE header is present as shown in Figure 7.
shown in Figure 7.
[IPv6-or-IPv4 Header] [IPv6 or IPv4 Header]
[GRE Header] [GRE Header]
[payload - IPv6-or-IPv4 Header] [Payload - IPv6 or IPv4 Header]
Upper Layer protocols Upper Layer protocols
Figure 7: IPv6-or-IPv4 over IPv4 Using GRE Encapsulation Figure 7: IPv6-or-IPv4 over IPv4 Using GRE Encapsulation
On the other hand, if the mobile access gateway is located in an 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 IPv4-only network where NAT has been detected on the path between the
mobile access gateway and the local mobility anchor and successfully mobile access gateway and the local mobility anchor and successfully
negotiated GRE encapsulation and the TLV-header format, the mobile negotiated GRE encapsulation and the TLV-header format, the mobile
access gateway MUST use UDP TLV-header tunneling format when sending access gateway MUST use UDP TLV-header tunneling format when sending
an IPv6 or IPv4 payload packet to the local mobility according to the an IPv6-or-IPv4 payload packet to the local mobility anchor according
format described in Figure 5. The source and the destination of the to the format described in Figure 5. The source and the destination
IPv4 outer header are mobile node IPv4 Proxy Care-of Address , IPv4- of the IPv4 outer header are mobile node IPv4 Proxy Care-of Address,
Proxy-CoA, and the IPv4 Local Mobility Anchor Address, IPv4-LMAA, IPv4-Proxy-CoA, and the IPv4 local mobility anchor address, IPv4-
respectively. In addition the source and the destination IP LMAA, respectively. In addition, the source and the destination IP
addresses of the IPv6-or-IPv4 payload data packet are the Mobile 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 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. IPv4 corresponding node's address, IPv6/IPv4-CN-Addr, respectively.
7.4. Local Mobility Anchor Operation 7.4. Local Mobility Anchor Operation
When the local mobility anchor receives a Proxy Binding Update When the local mobility anchor receives a Proxy Binding Update
encapsulated in UDP and containing the IPv4 home address option, it encapsulated in UDP and containing the IPv4 Home Address Request
needs to follow all the steps in [RFC5213] and [ID-PMIP6-IPv4]. In option ([RFC5844]), it needs to follow all the steps in [RFC5213] and
addition, if the TLV-header Format (T) flag is set in the Proxy [RFC5844]. In addition, if the TLV-header format (T) flag is set in
Binding Update, the local mobility anchor needs to determine whether the Proxy Binding Update, the local mobility anchor needs to
it can accept the TLV-header UDP based encapsulation format. If it determine whether it can accept the TLV-header UDP-based
does, it SHOULD set the TLV-header Format (T) flag in the Proxy encapsulation format. If it does, it SHOULD set the TLV-header
Binding Acknowledgement. Otherwise, the local mobility anchor MUST format (T) flag in the Proxy Binding Acknowledgement. Otherwise, the
NOT set the TLV-header Format (T) flag in the Proxy Binding local mobility anchor MUST NOT set the TLV-header format (T) flag in
Acknowledgement. the Proxy Binding Acknowledgement.
If the local mobility anchor receives a Proxy Binding Update with the If the local mobility anchor (LMA) receives a Proxy Binding Update
GRE Key option and TLV-header Format (T) flag set and based on a with the GRE Key option and TLV-header format (T) flag set and, based
policy check, the local mobility anchor determines that GRE on a policy check, the LMA determines that GRE encapsulation is
encapsulation is required and the local mobility anchor supports TLV- required and the LMA supports TLV-header tunneling and the LMA sent a
header tunneling and the local mobility anchor sent a successful successful Proxy Binding Acknowledgement with the TLV-header format
Proxy Binding Acknowledgement with the TLV-header Format (T) flag (T) flag set, the LMA MUST update the mobile node's Binding Cache
set, the local mobility anchor MUST update the mobile node's Binding entry described in Section 5.1 by setting the GRE-encapsulation-
Cache entry described in Section 5.1 by setting the GRE encapsulation
enabled flag and update the uplink and downlink GRE key fields. In enabled flag and update the uplink and downlink GRE key fields. In
addition, the local mobility anchor MUST set the UDP based TLV-Header addition, the LMA MUST set the UDP-based TLV-header format flag.
format flag.
If the local mobility anchor receives a Proxy Binding Update with the If the LMA receives a Proxy Binding Update with the GRE Key option
GRE Key option and TLV-header Format (T) flag set and based on a and TLV-header format (T) flag set and, based on a policy check, the
policy check, the local mobility anchor determines that GRE LMA determines that GRE encapsulation is required BUT the LMA does
encapsulation is required BUT the local mobility anchor does NOT NOT support TLV-header tunneling and if the Proxy Binding Update has
support TLV-header tunneling and if Proxy Binding Update has been been successfully processed, the LMA MUST send a successful Proxy
successfully processed, the local mobility anchor MUST send a Binding Acknowledgement with the status code
successful Proxy Binding Acknowledgement with the status code <GRE GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED. This way, the LMA
TUNNELING BUT TLV-HEADER NOT SUPPORTED>. This way, the local indicates to the mobile access gateway that GRE encapsulation has
mobility anchor indicates to the mobile access gateway that GRE been successfully negotiated BUT TLV-header UDP-based tunneling
encapsulation has been successfully negotiated BUT TLV-header UDP format is not supported. In this case, the LMA MUST update the
based tunneling format is not supported. In this case, the local mobile node's BCE described in Section 5.1 by setting the GRE
mobility anchor MUST update the mobile node BCE described in encapsulation enabled flag and update the uplink and downlink GRE key
Section 5.1 by setting the GRE encapsulation enabled flag and update fields. In this case, the LMA MUST set the UDP-based TLV-header
the uplink and downlink GRE key fields. In this case, the local format flag to FALSE.
mobility anchor MUST set the UDP based TLV-Header format flag to
FALSE.
If the local mobility anchor and the mobile access gateway have If the local mobility anchor and the mobile access gateway have
successfully negotiated the TLV-header UDP based tunneling format and successfully negotiated the TLV-header UDP-based tunneling format and
the GRE encapsulation for a specific mobility session, the local GRE encapsulation for a specific mobility session, the local mobility
mobility anchor processes data packets as described in the following anchor processes data packets as described in the following
subsection. subsection.
7.4.1. Sending and Receiving Data Packets 7.4.1. Sending and Receiving Data Packets
The local mobility anchor may use GRE encapsulation for tunneling The local mobility anchor may use GRE encapsulation for tunneling an
IPv6 or IPv4 payload data packet to the mobile access gateway. If IPv6 or IPv4 data packet to the mobile access gateway. If the local
the local mobility anchor has successfully negotiated GRE mobility anchor has successfully negotiated GRE encapsulation with
encapsulation with the mobile access gateway for a specific mobility the mobile access gateway for a specific mobility session, the local
session, the local mobility anchor encapsulates and decapsulates mobility anchor encapsulates and decapsulates IPv6-or-IPv4 payload
IPv6-or-IPv4 payload data packets following the rules described in data packets following the rules described in [RFC5213] and [RFC5844]
[RFC5213] and [ID-PMIP6-IPv4] while ensuring that the GRE header is while ensuring that the GRE header is present as shown in Figure 7.
present as shown in Figure 7.
In the case when TLV-tunneling format and the GRE encapsulation for a In the case when TLV-tunneling format and GRE encapsulation for a
specific mobility session have been successfully negotiated between specific mobility session have been successfully negotiated between
the local mobility anchor and the mobile access gateway, the local the local mobility anchor and the mobile access gateway, the local
mobility anchor follows the TLV-header UDP based tunneling format and mobility anchor follows the TLV-header UDP-based tunneling format and
headers order as shown in Figure 5 to encapsulate IPv4 or IPv6 header order as shown in Figure 5 to encapsulate IPv4 or IPv6 payload
payload packets in IPv4 before sending the IPv4 packet to the mobile packets in IPv4 before sending the IPv4 packet to the mobile access
access gateway. In this case, the source and the destination of the gateway. In this case, the source and the destination of the IPv4
IPv4 outer header are IPv4-LMAA and IPv4-Proxy-CoA, respectively. In outer header are IPv4-LMAA and IPv4-Proxy-CoA, respectively. In
addition the source and the destination IP addresses of the IPv6-or- 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, IPv4 payload data packet are IPv6/IPv4-CN-Addr and IPv6/IPv4-MN-HoA,
respectively. On the other hand, the local mobility anchor ensures respectively. On the other hand, the local mobility anchor ensures
the same TLV-header UDP based tunneling format and headers order when the same TLV-header UDP-based tunneling format and header order when
it decapsulates received IPv4 packets from the mobile access gateway it decapsulates received IPv4 packets from the mobile access gateway
for the same mobility session. for the same mobility session.
8. IANA Considerations 8. IANA Considerations
This specification defines a new Mobility Option, the GRE Key Option, This specification defines a new mobility option, the GRE Key option,
described in Section 6.1. This option is carried in the Mobility 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 Header. The type value for this option has been assigned from the
same numbering space as allocated for the other mobility options same numbering space as allocated for the other mobility options
defined in the Mobile IPv6 specification [RFC3775]. defined in the Mobile IPv6 specification [RFC3775].
This specification also defines three new Binding Acknowledgement This specification also defines three new Binding Acknowledgement
status codes as described in Section 6.4 and requests that these status codes as described in Section 6.4 and IANA has allocated the
three codes be allocated with numeric values as specified in numeric values as specified in Section 6.4 from the "Status Codes"
Section 6.4 from the "Status Codes" registry of the Mobility IPv6 registry of the Mobility IPv6 Parameters.
Parameters located at
http://www.iana.org/assignments/mobility-parameters.
9. Security Considerations 9. Security Considerations
The GRE Key Option, defined in this specification, that can be The GRE Key option, defined in this specification, when carried in
carried in Proxy Binding Update and Proxy Binding Acknowledgement Proxy Binding Update and Proxy Binding Acknowledgement messages,
messages, reveals the group affiliation of a mobile node identified reveals the group affiliation of a mobile node identified by its
by its Network Access Identifier (NAI) or an IP address. It may help Network Access Identifier (NAI) or an IP address. It may help an
an attacker in targeting flows belonging to a specific group. This attacker in targeting flows belonging to a specific group. This
vulnerability can be prevented, by enabling confidentiality vulnerability can be prevented, by enabling confidentiality
protection on the Proxy Binding Update and Proxy Binding protection on the Proxy Binding Update and Proxy Binding
Acknowledgement messages where the presence of the NAI and GRE Key Acknowledgement messages where the presence of the NAI and GRE Key
Options establish a mobile node's relation to a specific group. This options establish a mobile node's relation to a specific group. This
vulnerability can also be avoided by enabling confidentiality vulnerability can also be avoided by enabling confidentiality
protection on all the tunneled data packets between the mobile access protection on all the tunneled data packets between the mobile access
gateway and the local mobility anchor, for hiding all the markings. gateway and the local mobility anchor, for hiding all the markings.
In Proxy Mobile IPv6 [RFC5213], the use of IPsec [RFC4301] for In Proxy Mobile IPv6 [RFC5213], the use of IPsec [RFC4301] for
protecting a mobile node's data traffic is optional. Additionally, protecting a mobile node's data traffic is optional. Additionally,
Proxy Mobile IPv6 recommends the use of Encapsulating Security Proxy Mobile IPv6 recommends the use of Encapsulating Security
Payload (ESP) [RFC4303] in tunnel mode when using ESP in protecting Payload (ESP) [RFC4303] in tunnel mode when using ESP for protecting
the mobile node's data traffic. However, when GRE encapsulation is the mobile node's data traffic. However, when GRE encapsulation is
used, both IPsec tunnel mode and transport mode can be used to used, both IPsec tunnel mode and transport mode can be used to
protect the GRE header. The IPsec traffic selectors will contain the protect the GRE header. The IPsec traffic selectors will contain the
protocol number for GRE, and there is currently no mechanism to use protocol number for GRE, and there is currently no mechanism to use
the GRE key as a traffic selector. the GRE key as a traffic selector.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Alessio Casati, Barney Barnowski, The authors would like to thank Alessio Casati, Barney Barnowski,
Mark Grayson and Parviz Yegani for their input on the need for this Mark Grayson, and Parviz Yegani for their input on the need for this
option. The authors would like to thank Charlie Perkins, Curtis option. The authors would like to thank Charlie Perkins, Curtis
Provost, Irfan Ali, Jouni Korhonen, Julien Laganier, Kuntal Provost, Irfan Ali, Jouni Korhonen, Julien Laganier, Kuntal
Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review
and comments. and comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996. October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 23, line 32 skipping to change at page 22, line 35
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000. RFC 2890, September 2000.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[ID-PMIP6-IPv4] [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-12
(work in progress), April 2009.
11.2. Informative References 11.2. Informative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
"Multiple Care-of Addresses Registration", and K. Nagami, "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-13 (work in progress), RFC 5648, October 2009.
April 2009.
Authors' Addresses Authors' Addresses
Ahmad Muhanna Ahmad Muhanna
Nortel Ericsson, Inc.
2221 Lakeside Blvd. 2201 Lakeside Blvd.
Richardson, TX 75082 Richardson, TX 75082
USA USA
Email: amuhanna@nortel.com EMail: ahmad.muhanna@ericsson.com
Mohamed Khalil Mohamed Khalil
Nortel Ericsson, Inc.
2221 Lakeside Blvd. 6300 Legacy Dr.
Richardson, TX 75082 Plano, TX 75024
USA USA
Email: mkhalil@nortel.com EMail: Mohamed.khalil@ericsson.com
Sri Gundavelli Sri Gundavelli
Cisco Systems Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sgundave@cisco.com EMail: sgundave@cisco.com
Kent Leung Kent Leung
Cisco Systems Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: kleung@cisco.com EMail: kleung@cisco.com
 End of changes. 148 change blocks. 
392 lines changed or deleted 374 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/