draft-ietf-netlmm-grekey-option-03.txt   draft-ietf-netlmm-grekey-option-04.txt 
Network Working Group A. Muhanna Network Working Group A. Muhanna
Internet-Draft M. Khalil Internet-Draft M. Khalil
Intended status: Standards Track Nortel Intended status: Standards Track Nortel
Expires: August 1, 2009 S. Gundavelli Expires: August 20, 2009 S. Gundavelli
K. Leung K. Leung
Cisco Systems Cisco Systems
January 28, 2009 February 16, 2009
GRE Key Option for Proxy Mobile IPv6 GRE Key Option for Proxy Mobile IPv6
draft-ietf-netlmm-grekey-option-03.txt draft-ietf-netlmm-grekey-option-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 1, 2009. This Internet-Draft will expire on August 20, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Abstract Abstract
This document defines a new Mobility Option for allowing the mobile This specification defines a new Mobility Option for allowing the
access gateway and the local mobility anchor to negotiate GRE mobile access gateway and the local mobility anchor to negotiate GRE
encapsulation mode and exchange the downlink and uplink GRE keys (Generic Routing Encapsulation) encapsulation mode and exchange the
which are used for marking the downlink and uplink traffic that downlink and uplink GRE keys which are used for marking the downlink
belong to a specific mobile node session or a specific flow. and uplink traffic that belong to a specific mobility session. In
addition, the same mobility option is used to explicitly negotiate
the GRE encapsulation mode only without exchanging the GRE keys.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. GRE Encapsulation and Key Exchange . . . . . . . . . . . . . . 4 3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . . . 5
3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 4 3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 5
3.2. GRE Encapsulation Support . . . . . . . . . . . . . . . . 6 3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 7
3.3. GRE Key Exchange Mechanism . . . . . . . . . . . . . . . . 6 3.3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . 7
3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 6 3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 7
3.3.2. GRE Key Exchange During Binding Re-registration . . . 6 3.3.2. GRE Key Exchange During Binding Re-registration . . . 8
4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 7 4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 9
4.1. Extensions to the Conceptual Data Structure . . . . . . . 7 4.1. Extensions to the Conceptual Data Structure . . . . . . . 9
4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 8 4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 9
5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 9 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 11
5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 9 5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 11
5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 10 5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 11
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 11 6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Proxy Binding Update Message Extension . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.3. Proxy Binding Acknowledgement Message Extension . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. Data Packets Processing Considerations . . . . . . . . . . . . 16
10. Normative References . . . . . . . . . . . . . . . . . . . . . 14 7.1. Tunneling Format . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. TLV-header Tunneling Negotiation . . . . . . . . . . . . . 17
7.3. Mobile Access Gateway Operation . . . . . . . . . . . . . 18
7.3.1. Sending and Receiving Data Packets . . . . . . . . . . 19
7.4. Local Mobility Anchor Operation . . . . . . . . . . . . . 20
7.4.1. Sending and Receiving Data Packets . . . . . . . . . . 21
7.5. Mobile Node Operation . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The base Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile IPv6
IPv6 support for IPv4 [ID-PMIP6-IPv4] allow the use of IPv6 and IPv4 support for IPv4 [ID-PMIP6-IPv4] allow the use of IPv6 and IPv4
encapsulation modes [RFC2473][RFC2003] for the tunneled traffic encapsulation modes [RFC2473][RFC2003] for the tunneled traffic
between the local mobility anchor and the mobile access gateway. between the local mobility anchor and the mobile access gateway.
There are scenarios where these encapsulation modes are not There are scenarios where these encapsulation modes are not
sufficient to uniquely identify the destination of packets of a sufficient to uniquely identify the destination of packets of a
specific flow. Thus, there is a need for an encapsulation mode with specific binding. Thus, there is a need for an encapsulation mode
richer semantics. The Generic Routing Encapsulation [RFC2784] and with richer semantics. The Generic Routing Encapsulation (GRE)
the Key extension as defined in [RFC2890], has the required semantics [RFC2784] and the Key extension as defined in [RFC2890], has the
to allow such distinction for use in Proxy Mobile IPv6. required semantics to allow such distinction for use in Proxy Mobile
IPv6.
This document 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 the exchange of the uplink negotiation of GRE encapsulation mode and exchange of the uplink and
and downlink GRE keys. The negotiated downlink and uplink GRE keys downlink GRE keys. The negotiated downlink and uplink GRE keys can
can be used for marking the downlink and uplink traffic for a be used for marking the downlink and uplink traffic for a specific
specific mobility session or a specific flow. mobility session. In addition, this specification enables the mobile
access gateway and the local mobility anchor to explicitly negotiate
the GRE encapsulation mode only using a special flag in the GRE Key
mobility option.
2. Conventions & Terminology 2. Conventions & 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
document are to be interpreted as described in RFC 2119 [RFC2119]. specification are to be interpreted as described in RFC 2119
[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 specification [RFC3775] and be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile
Proxy Mobile IPv6 specification [RFC5213]. The following terms are IPv6 [RFC5213] specifications. The following terms are used in this
used in this document. 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 which
belongs to a specific mobility session or flow as described in belongs to a specific mobility session as described in this
this document. 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 which belongs
to a specific mobility session or flow as described in this to a specific mobility session as described in this specification.
document.
3. GRE Encapsulation and Key Exchange A Policy Check
When LMA receives an initial, handoff-triggered Binding Lifetime
Extension, or Binding Lifetime Extension Proxy Binding Update for
a mobility session, the LMA determines if the GRE encapsulation
mode only or GRE encapsulation and GRE keys are required based on
a policy check. This policy could be a per MAG-LMA peer, a per-
LMA local policy, a per-MN policy, or the combination of all.
3. GRE Encapsulation and Keys Exchange
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 and exchange the GRE keys for marking the downlink encapsulation mode only or GRE encapsulation mode and exchange the
and uplink traffic. GRE keys for marking the downlink and uplink traffics. In the case
when GRE encapsulation mode only is negotiated between the MAG and
LMA, the mechanism used to exchange or deliver these GRE keys, if
used, to the MAG and LMA is out-of scope of this specification.
Once the GRE keys have been exchanged between the mobile access However, once the GRE keys have been exchanged between the mobile
gateway and the local mobility anchor, the mobile access gateway will access gateway and the local mobility anchor as per this
use the uplink GRE key that is assigned by the local mobility anchor specification, the mobile access gateway will use the uplink GRE key
in the GRE encapsulation header of the uplink payload packet. that is assigned by the local mobility anchor in the GRE header of
Similarly, the local mobility anchor will use the downlink GRE key as the uplink payload packet. Similarly, the local mobility anchor will
negotiated with the mobile access gateway in the GRE encapsulation use the downlink GRE key as negotiated with the mobile access gateway
header of the downlink payload packet. in the GRE header of the downlink payload packet.
The following illustration explains the use of GRE encapsulation mode The following illustration explains the use of GRE encapsulation mode
and the GRE keys for supporting the usecase where overlapping IPv4 and the GRE keys for supporting the usecase where overlapping IPv4
private address [RFC1918] allocation is in use. private address [RFC1918] allocation is in use.
+------------+ +------------+
| Operator-A | | Operator-A |
| | | |
| 10.x.0.0/16| | 10.x.0.0/16|
+------------+ +------------+
skipping to change at page 5, line 28 skipping to change at page 6, line 33
| | ========================== | | \ | | ========================== | | \
MN-4---| | Proxy Mobile IPv6 Tunnel | | \ MN-4---| | Proxy Mobile IPv6 Tunnel | | \
+------+ +------+ \ +------+ +------+ \
\ \
Operator-C: Access Network +------------+ Operator-C: Access Network +------------+
| Operator-B | | Operator-B |
| | | |
| 10.x.0.0/16| | 10.x.0.0/16|
+------------+ +------------+
Figure 1: Overlapping IPv4 Private Address Space 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 distinguish the flows belonging to a given anchor must be able to distinguish the flows belonging to a given
operator from the flows belonging to some other operator. operator from the flows belonging to some other operator.
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
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 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. tunneled payload packet, and route them accordingly. However, the
GRE keys as in this specification apply to the individual mobility
binding updated by the Proxy Binding Update but not to all bindings
that the mobile may have registered following procedures described in
[ID-MCoA].
3.2. GRE Encapsulation Support 3.2. GRE Encapsulation Mode Only
To request GRE encapsulation support, the mobile access gateway MUST In order for the mobile access gateway to request GRE encapsulation
include the GRE Key option in the Proxy Binding Update message sent mode only without exchanging the GRE keys, the mobile access gateway
to the local mobility anchor. In case, the mobile access gateway MUST include the GRE Key option in the Proxy Binding Update with the
wants to use GRE encapsulation without the GRE keys, it MUST NOT Key NOT Used (K) bit set. In this case, the MAG MAY set the GRE Key
include the GRE Key Identifier in the option. Identifier field to any value including zero.
If the local mobility anchor supports GRE encapsulation and the Proxy If the local mobility anchor supports GRE encapsulation and the
Binding Update processing is successful, the LMA sends a Proxy received Proxy Binding Update contains the GRE Key option with the
Binding Acknowledgement with the GRE Key option. If GRE Key NOT Used (K) bit set, the mobile access gateway is requesting GRE
encapsulation is being used without the GRE keys, the LMA MUST NOT encapsulation without exchanging the GRE keys dynamically. The local
include the GRE Key Identifier in the GRE option. mobility anchor MUST ignore the key in the GRE Key Identifier as it
is not used. If the Proxy Binding Update processing is successful,
the LMA sends a successful Proxy Binding Acknowledgement message with
the GRE Key option included. In this case, the local mobility anchor
MUST set the Key NOT Used (K) bit in the GRE Key option and may set
the GRE Key Identifier to any value including zero.
3.3. GRE Key Exchange Mechanism When the mobile access gateway and the local mobility anchor
successfully negotiate the GRE encapsulation mode only, the mechanism
of making the GRE keys, if being used, available to the MAG and LMA
is out-of scope of this specification.
3.3. GRE Encapsulation and Keys 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 exchange downlink and uplink GRE keys using the local mobility anchor negotiate GRE encapsulation and exchange
proxy mobile IPv6 registration procedure. downlink and uplink GRE keys using proxy mobile IPv6 registration
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 MAG local policy, or the MAG-LMA IPv4 address support [RFC1918], the MAG local policy, or the MAG-LMA
peer agreement, that GRE encapsulation is needed and GRE keys are peer agreement, that GRE encapsulation is needed and GRE keys are
required, the mobile access gateway MUST include the GRE Key option required, the mobile access gateway MUST include the GRE Key option
in the initial Proxy Binding Update message sent to the local in the initial Proxy Binding Update message sent to the local
mobility anchor. The mobile access gateway MUST include the downlink mobility anchor. The mobile access gateway MUST include the downlink
GRE key in the GRE Key Identifier field of the GRE Key option. GRE key in the GRE Key Identifier field of the GRE Key option.
After successfully processing the initial Proxy Binding Update and After the LMA successfully processes the initial Proxy Binding Update
accepting the downlink GRE key, the LMA MUST include the GRE Key and accepts the GRE encapsulation request and the downlink GRE key
option with the uplink GRE key in the GRE Key Identifier field when based on a policy check, the LMA MUST include the GRE Key option with
sending a successful Proxy Binding Acknowledgement to the MAG. the uplink GRE key in the GRE Key Identifier field in a successful
Proxy Binding Acknowledgement and send it to the MAG.
3.3.2. GRE Key Exchange During Binding Re-registration 3.3.2. GRE Key Exchange During Binding Re-registration
If the MAG has successfully negotiated and exchanged the initial GRE If the MAG has successfully negotiated and exchanged the initial GRE
keys with the LMA for a specific binding, the MAG SHOULD NOT include keys with the LMA for a specific mobile node binding, the MAG MUST
the GRE Key option with the downlink GRE key in the Proxy Binding include the GRE Key option with the downlink GRE key in the Proxy
Update which is used for requesting a Binding Lifetime Extension. Binding Update which is used for requesting a Binding Lifetime
Extension.
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
MAG local policy, the MAG-LMA peer agreement, or an indication during MAG local policy, the MAG-LMA peer agreement, or an indication during
the handoff process, that GRE encapsulation and GRE key exchange is the handoff process, that GRE encapsulation and GRE key exchange is
required, the new mobile access gateway MUST include the GRE key required, the new mobile access gateway MUST include the GRE key
option with the downlink GRE key in the Proxy Binding Update which is option with the downlink GRE key in the Proxy Binding Update which is
used for requesting an after handoff Binding Lifetime extension. In used for requesting an after handoff Binding Lifetime extension. In
this case, the new MAG may either pick a new downlink GRE key or use this case, the new MAG may either pick a new downlink GRE key or use
the downlink GRE key that was used by the previous MAG for the same the downlink GRE key that was used by the previous MAG for the same
binding. For the new MAG to know the downlink GRE key used by the binding. For the new MAG to know the downlink GRE key used by the
previous MAG, it may require transfer of context from the previous previous MAG, it may require transfer of context from the previous
MAG to the new MAG during a handoff. Such mechanisms are out-of- MAG to the new MAG during a handoff. Such mechanisms are out-of-
scope for this document. scope for this specification.
If the LMA successfully processes a handoff-triggered Binding If the LMA successfully processes a handoff-triggered Binding
Lifetime Extension Proxy Binding Update message which contains a GRE Lifetime Extension Proxy Binding Update message which contains a GRE
key option with a downlink GRE key included, the LMA MUST return the key option with a downlink GRE key included, the LMA MUST return the
same uplink GRE key that was exchanged with the previous MAG and is same uplink GRE key that was exchanged with the previous MAG and is
saved in the respected Binding Cache Entry (BCE). saved in the respected Binding Cache Entry (BCE) in the GRE key
option in a successful Proxy Binding Acknowledgement message sent to
the new MAG.
If the LMA receives handoff-triggered Binding Lifetime Extension If the LMA receives a handoff-triggered Binding Lifetime Extension
Proxy Binding Update message without the GRE key option for a BCE Proxy Binding Update message without the GRE key option for a BCE
that is using GRE keys and GRE encapsulation, the LMA MUST reject the that is using GRE keys and GRE encapsulation, the LMA makes a policy
Proxy Binding Update by sending a Proxy Binding Acknowledgement check regarding GRE encapsulation and GRE keys exchange. If,
message with the status field is set to <GRE KEY OPTION REQUIRED> as according to the policy check, GRE encapsulation and GRE Keys
defined in Section 6.2. If the LMA is preconfigured to use a exchange are required, the LMA MUST reject the Proxy Binding Update
different mechanism other than GRE encapsulation with the MAG which by sending a Proxy Binding Acknowledgement message with the status
sent the handoff-triggered Binding Lifetime Extension Proxy Binding field is set to <GRE KEY OPTION REQUIRED> as defined in Section 6.4.
Update, the LMA MAY accept the PBU and if it is successfully Otherwise, the LMA SHOULD accept the Proxy Binding Update and if it
processed, the LMA returns a successful PBA without the GRE Key is processed successfully, the LMA MUST return a successful PBA
option. In this case, mapping between the current GRE keys and the without including the GRE Key option.
other mechanism identifiers or labels is outside the scope of this
specification.
Typically, the MAG does not include the GRE Key Option in a Proxy
Binding Update message sent to refresh an existing binding. However,
if the LMA receives a Proxy Binding Update from the current MAG to
extend the existing binding, and the Proxy Binding Update messages
contains the GRE Key option and the downlink GRE Key identifier, it
MUST NOT reject the Proxy Binding Update message. In this case, the
LMA processes the Proxy Binding Update normally and if the included
downlink GRE key is different than the one saved in the respected
BCE, the LMA MUST update the BCE with the new downlink GRE key.
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 three new
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.
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 MAG and communicated to the LMA in the GRE key is generated by the MAG and communicated to the LMA in the
GRE Key option in the Proxy Binding Update message. GRE Key option in the Proxy 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 LMA as specified in this Acknowledgement message sent by the LMA as specified in this
document. specification.
4.2. Operational Summary 4.2. Operational Summary
o If the MAG determines that GRE encapsulation and GRE key is o If the MAG determines that GRE encapsulation mode only is
required, the MAG MUST include the GRE Key option with the Key NOT
Used (K) bit set in the Proxy Binding Update message that is sent
to the local mobility anchor. The MAG MAY set the GRE Key
Identifier to any value as it is not being used.
o If the MAG determines that GRE encapsulation and GRE keys are
required, the MAG MUST include the GRE Key option with the required, the MAG MUST include the GRE Key option with the
downlink GRE key in the GRE Key Identifier field in the Proxy downlink GRE key in the GRE Key Identifier field in the Proxy
Binding Update message that is sent by the mobile access gateway Binding Update message that is sent to the local mobility anchor.
to the local mobility anchor.
o After receiving a successful Proxy Binding Acknowledgment message o After receiving a successful Proxy Binding Acknowledgment message
with the GRE Key option which includes the uplink GRE key, the with the GRE Key option with the Key NOT Used (K) bit set, the
mobile access gateway MUST update the related three fields in the mobile access gateway MUST update the mobile node Binding Update
mobile node Binding Update List entry described in Section 4.1. List entry described in Section 4.1 by only setting the GRE
Additionally, the MAG MUST use the assigned uplink GRE Key for encapsulation enabled flag.
tunneling all the traffic originating from the mobile node before
forwarding the tunneled traffic to the LMA.
o If the mobile access gateway included the GRE Key option in the o After receiving a successful Proxy Binding Acknowledgment message
with the GRE Key option with the Key NOT Used (K) bit cleared and
the uplink GRE key included, the mobile access gateway MUST update
the related three fields in the mobile node Binding Update List
entry described in Section 4.1. Additionally, the MAG MUST use
the assigned uplink GRE Key for tunneling all the traffic that
belong to this mobile node BUL entry and is originated from the
mobile node before forwarding the tunneled traffic to the LMA.
o If the mobile access gateway includes the GRE Key option in the
Proxy Binding Update for a specific mobile node and the local 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 GRE Key option, then the mobile access gateway MUST consider the GRE Key option, then the mobile access gateway MUST consider
that the local mobility anchor does not support GRE Key option as that the local mobility anchor does not support 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 LMA. message that is sent to that LMA.
skipping to change at page 9, line 19 skipping to change at page 10, line 45
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 MAG does not support the message with the GRE Key option. If the MAG does not support the
GRE Key option, the MAG MAY log the event and possibly raise an GRE Key option, the MAG MAY log the event and possibly raise an
alarm to indicate a possible misconfiguration. 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 a
status code <GRE KEY OPTION NOT REQUIRED>, the mobile access 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 is not
required for this specific binding. The MAG follows the Proxy required for this specific mobility binding. The MAG follows
Mobile IPv6 specification [RFC5213] for the handling of uplink and procedures in Proxy Mobile IPv6 specification [RFC5213] for the
downlink traffic for this mobile node binding and MUST NOT include handling of uplink and downlink traffic for this mobility binding
the GRE Key option in any subsequent Proxy Binding Update message and MUST NOT include the GRE Key option in any subsequent Proxy
for this specific mobile node that are sent to that LMA. Binding Update message that is sent to the LMA for this mobility
session.
o If the MAG sent a re-registration Proxy Binding Update message
without the GRE Key option, but received a successful Proxy
Binding Acknowledgement which includes the GRE Key option with the
uplink GRE key, the MAG MUST compare the received uplink GRE key
with the one saved in the respected Binding Update List entry and
update it if the received uplink GRE key is different.
o If the MAG has successfully negotiated and exchanged the initial o If the MAG has successfully negotiated GRE encapsulation and
GRE keys with the LMA for a specific binding, the MAG SHOULD NOT exchanged the GRE keys with the LMA for a specific mobility
include the GRE Key option in the de-registration Proxy Binding session, the MAG SHOULD NOT include the GRE Key option in the de-
Update. registration Proxy Binding Update.
o On receiving a packet from the tunnel with the GRE encapsulation o On receiving a packet from the tunnel with the GRE header, the
header, the mobile access gateway MUST use the GRE Key to mobile access gateway MUST use the GRE Key present in the GRE
determine the necessary special processing for the data packet, extension header as an additional identifier to determine which
e.g., lookup the mobile node's layer-2 address, determine any mobility session this packet belongs to. The GRE header is
special processing or treatment for the data packet flow, then removed before further processing takes place.
remove the encapsulation header before forwarding the packet.
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 negotiates 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 BCE. This requires and uplink GRE keys as part of the mobile node BCE. This requires
that the BCE described in section 5.1 of the Proxy Mobile IPv6 base that the BCE described in section 5.1 of the Proxy Mobile IPv6 base
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 three
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 MAG and used in the GRE o The downlink GRE Key, assigned by the MAG and used in the GRE
encapsulation header of the tunneled payload packet from the local encapsulation header of the tunneled payload packet from the local
mobility anchor to the mobile access gateway. mobility anchor to the mobile access gateway.
o The Uplink GRE Key, assigned by the LMA and used in the GRE o The Uplink GRE Key, assigned by the LMA and used in the GRE
encapsulation header of the tunneled payload packet from the encapsulation header of the tunneled payload packet from the
mobile access gateway to the local mobility anchor. mobile access gateway to the local mobility anchor.
5.2. Operational Summary 5.2. Operational Summary
o After successfully processing a Proxy Binding Update message with o If local mobility anchor successfully processes a Proxy Binding
the GRE Key option which includes a downlink GRE key in the GRE Update message with the GRE Key option with the Key NOT Used (K)
Key Identifier field for Initial GRE Key exchange as in bit set for Initial GRE Key exchange, the local mobility anchor
Section 3.3.1, the local mobility anchor MUST include the GRE Key MUST include the GRE Key option with the Key NOT Used (K) bit set
option with the uplink GRE key in the GRE Key Identifier field
when responding with a successful Proxy Binding Acknowledgement when responding with a successful Proxy Binding Acknowledgement
message. message. The LMA MAY set the GRE Key Identifier field in the GRE
key option to any value including zero.
o If the local mobility anchor successfully processes a Proxy
Binding Update message with the GRE Key option with the Key NOT
Used (K) bit cleared and downlink GRE key included in the GRE Key
Identifier field for Initial GRE Key exchange as in Section 3.3.1,
the local mobility anchor MUST include the GRE Key option with the
Key NOT Used (K) bit cleared and the uplink GRE key included in
the GRE Key Identifier field when responding with a successful
Proxy Binding Acknowledgement message.
o If the GRE tunneling is negotiated and the downlink and uplink GRE 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 binding, the local mobility local mobility anchor for a specific mobility binding, the local
anchor MUST use the negotiated downlink GRE key in the GRE header mobility anchor MUST use the negotiated downlink GRE key in the
of every packet that is destined to the mobile node of this GRE header of every packet that is destined to the mobile node of
specific binding over the GRE tunnel to the mobile access gateway. this specific binding over the GRE tunnel to the mobile 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 determines that GRE Key option, and if the local mobility anchor based on a policy
GRE encapsulation and GRE key is required, e.g., overlapping IPv4 check determines that GRE encapsulation and GRE keys are required,
private addressing is in use, LMA local policy or LMA-MAG peer e.g., overlapping IPv4 private addressing is in use, LMA local
policy, the local mobility anchor MUST reject the request and send policy or LMA-MAG peer agreement, the local mobility anchor MUST
the Proxy Binding Acknowledgement message to the mobile access reject the request and send a Proxy Binding Acknowledgement
gateway with the status code <GRE KEY OPTION REQUIRED> as defined message to the mobile access gateway with the status code <GRE KEY
in Section 6.2, indicating that GRE encapsulation and GRE key is OPTION REQUIRED> as defined in Section 6.4, indicating that GRE
required. encapsulation and GRE keys are required.
o If after receiving Proxy Binding Update message with the GRE Key o If after receiving and successfully processing a Proxy Binding
option and successfully processes the Proxy Binding Update, the Update message with the GRE Key option, the local mobility anchor
local mobility anchor determines that GRE encapsulation and key determines based on a policy check that GRE encapsulation and GRE
exchange is not required for this specific binding, e.g., private keys are not required for this specific binding, e.g., private
IPv4 addressing is not in use, the LMA MUST send a Proxy Binding IPv4 addressing is not in use, the LMA MUST send a successful
Acknowledgement message to the MAG with the status code <GRE KEY Proxy Binding Acknowledgement message to the MAG with the status
OPTION NOT REQUIRED>. The local mobility anchor MUST NOT include code <GRE KEY OPTION NOT REQUIRED>. The local mobility anchor
the GRE Key option in that Proxy Binding Acknowledgement. MUST NOT include the GRE Key option in this 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 which contains a GRE Key registration Proxy Binding Update message, the LMA follows the
option with a downlink GRE key included, the LMA follows the same same de-registration process as described in Proxy Mobile IPv6
de-registration process as per the base Proxy Mobile IPv6
specification [RFC5213] to clean the binding cache entry and all specification [RFC5213] to clean the binding cache entry and all
associated resources including the downlink and uplink GRE keys. associated resources including the downlink and uplink GRE keys.
o On receiving a packet from the tunnel with the GRE encapsulation o On receiving a packet from the tunnel with the GRE header, the
header, the local mobility anchor MUST use the GRE Key present in local mobility anchor MUST use the GRE Key in the GRE extension
the GRE extension header to determine the necessary special header as an additional identifier to determine which mobility
processing for the data packet, e.g., lookup the mobile node's session this packet belongs to. The GRE header is removed before
home gateway address, determine any special processing or further processing takes place.
treatment for the data packet flow, then remove the encapsulation
header before forwarding the packet.
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 [RFC3775]
protocol messages. The use of GRE Key option for supporting GRE protocol messages. The use of 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 document. 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 Acknowledgment 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 and exchanging the downlink and uplink GRE keys that can be used mode only or GRE encapsulation and exchanging the downlink and uplink
by the peers in all GRE encapsulated packets for marking that GRE keys. These GRE keys can be used by the peers in all GRE
specific mobile node's data flow. encapsulated payload packets for marking that specific mobile node's
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
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 | Length | Reserved | | Type | Length |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key Identifier | | GRE Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: GRE Key Option Figure 2: GRE Key Option
Type Type
<IANA> <IANA>
Length Length
8-bit unsigned integer indicating the length in octets of the 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. The Length field is
is set to 2, it indicates that the GRE key is not being carried in always set to 6.
the option. If the length field is set to a value of 6, it means
that either the downlink or the uplink GRE key is carried. Key NOT Used (K)
The Key NOT Used (K) bit is set by the mobile access gateway to
request GRE encapsulation mode only as in Section 3.2. If the (K)
bit is set, the local mobility anchor and the mobile access
gateway MUST ignore the value in the GRE Key Identifier field.
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 32-bit field contains the downlink or uplink GRE key. The value
field is present in the GRE Key option only if the GRE keys are in this field is ignored when the Key NOT Used (K) bit set.
being exchanged using the Proxy Binding Update and Proxy Binding
Acknowledgement messages.
6.2. Status Codes 6.2. Proxy Binding Update Message Extension
This specification extends the Proxy Binding Update message with one
new flag. The flag is shown and described below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Proxy Binding Update message
TLV-header Format (T)
When set, this flag indicates that the mobile access gateway
requests the use of the TLV-header for encapsulating IPv6-or-IPv4
in IPv4. The TLV-header format is described later in this
specification.
6.3. Proxy Binding Acknowledgement Message Extension
This specification extends the Proxy Binding Acknowledgement message
with a new flag. This new flag is shown and described below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|T| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Proxy Binding Acknowledgement Message
TLV-header Format (T)
When set, this flag indicates that the sender of the Proxy Binding
Acknowledgement (LMA) supports tunneling IPv6-or-IPv4 in IPv4
using TLV-header format.
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. Acknowledgment message when using Proxy Mobile IPv6.
GRE KEY OPTION NOT REQUIRED (TBD less than 128) GRE KEY OPTION NOT REQUIRED (TBD less than 128)
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 the GRE encapsulation is not with the GRE Key option while based on a policy check the LMA
required for this specific mobile node, the LMA uses this code to determines that the GRE encapsulation is not required for this
indicate to the mobile access gateway that the Proxy Binding specific mobility session, the LMA uses this code to indicate to
Update has been processed successfully but GRE Encapsulation and the mobile access gateway that the Proxy Binding Update has been
GRE Key is not required. processed successfully but GRE Encapsulation and GRE Key is not
required.
GRE KEY OPTION REQUIRED (TBD more than 128) GRE KEY OPTION REQUIRED (TBD more than 128)
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 the GRE encapsulation is required without the GRE Key option while based on a policy check the local
for this specific mobile node, the local mobility anchor uses this mobility anchor determines that GRE encapsulation is required for
code to reject the Proxy Binding Update and indicate to the mobile this specific mobility session, the local mobility anchor uses
access gateway that GRE Encapsulation and Keys is required. this code to reject the Proxy Binding Update and indicate to the
mobile access gateway that GRE Encapsulation and Keys are
required.
GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED (TBD less than 128)
7. IANA Considerations If local mobility anchor receives a Proxy Binding Update with the
GRE Key option and TLV-header Format (T) flag set, the local
mobility anchor uses this code to indicate to the mobile access
gateway that GRE Encapsulation has successfully been negotiated
BUT TLV-header format is NOT supported.
This document defines a new Mobility Option, the GRE Key Option, 7. Data Packets Processing Considerations
This section describes how the local mobility anchor and mobile
access gateway encapsulate and decapsulate data packets when GRE
encapsulation and GRE Keys are used for tunneling mobile nodes data
traffic between these two mobility nodes.
7.1. Tunneling Format
When GRE encapsulation and GRE keys have been negotiated between the
mobile access gateway and the local mobility anchor for a specific
mobility session, the mobile access gateway is allowed to use various
tunneling formats depending on the mobile access gateway location and
the networks's capabilities between the MAG and the LMA. While using
GRE encapsulation, the mobile access gateway can tunnel IPv6-or-IPv4
in IPv6 and IPv6-or-IPv4 in IPv4 using vanilla GRE tunneling based on
what described in [RFC5213] and [ID-PMIP6-IPv4], or use UDP
encapsulation to tunnel IPv6-or-IPv4 in IPv4.
If UDP-based tunnelling is used between the mobile access gateway and
the local mobility anchor after NAT has been detected in the path
between the MAG and the LMA while GRE encapsulation is required, the
TLV-header UDP tunneling format as shown in Figure 5 and described in
this specification MUST be used.
[IPv4 Header]
[UDP Header]
[TLV Header]
[GRE Header]
[payload - IPv6-or-IPv4 Header]
Upper Layer protocols
Figure 5: TLV-header UDP Based Encapsulation Headers Order
When UDP based tunneling format is used between the mobile access
gateway and the local mobility anchor, the use of the TLV-header is
negotiated during the Proxy Binding Update/Acknowledgement exchange
as described in Section 7.3 and Section 7.4. If the TLV-header
format is agreed upon between the mobile access gateway and local
mobility anchor, the LMA expects the TLV-header to follow the UDP
header as shown in Figure 5. The TLV header contains the type of the
following payload packet and its length. The Type field in the TLV-
header is limited to the values of 0 and 1 to ensure that the
receiver can differentiate whether what after the UDP header is a
TLV-header Type field or an IP version field of an IP header. Hence,
the TLV-header can carry traffic other than IP. The distinction
between IP and TLV encapsulation is needed because the Proxy Binding
Update will never be sent in TLV-header UDP tunnel format.
7.2. TLV-header Tunneling Negotiation
The mobile access gateway negotiates the format for tunnelling
payload traffic during Proxy Mobile IPv6 registration procedure. If
the mobile access gateway is required to use the TLV-header UDP
encapsulation format, the mobile access gateway MUST set the TLV-
header Format (T) flag in the Proxy Binding Update message sent to
the local mobility anchor. If the local mobility anchor supports the
TLV-header UDP tunneling format, the LMA SHOULD set the TLV-header
Format (T) flag in the Proxy Binding Acknowledgement. Otherwise, the
TLV-header Format (T) flag is cleared. The setting of the TLV-header
Format (T) flag in the Proxy Binding Acknowledgement indicates to the
mobile access gateway that it MUST use the TLV-header UDP
encapsulation format for all packets tunneled to the LMA for the
entire duration the mobile node is attached to the mobile access
gateway. The TLV-header UDP tunneling format SHOULD NOT change
during a Binding Lifetime Extension Proxy Binding Update (re-
registration) from the same mobile access gateway.
Any handoff-triggered Binding Lifetime Extension Proxy Binding Update
message may renegotiate the tunnelling format. Therefore, in order
to avoid interoperability issues, the local mobility anchor MUST NOT
set the TLV-header Format (T) flag unless it was set in the Proxy
Binding Update received from the mobile access gateway.
The TLV-header format is as shown below in Figure 6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TLV-header Format
Type
4-bit unsigned integer indicates the type of the payload following
this header. The following are the only defined values as per
this specification.
0 Reserved
1 Generic Routing Encapsulation (GRE) [RFC2784]
Length
16-bit unsigned integer indicating the length in octets of the
payload following this header, excluding the TLV-header itself.
Reserved
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
7.3. Mobile Access Gateway Operation
When sending an IPv6 packet containing a Proxy Binding Update while
the network between the mobile access gateway and local mobility
anchor is an IPv4-only network, the mobile access gateway follows the
procedures specified in [ID-PMIP6-IPv4] and [ID-DSMIP6] if vanilla
UDP encapsulation format is used. However, if GRE encapsulation is
required and UDP based encapsulation is used, the mobile access
gateway MUST set the TLV-header Format (T) flag in the Proxy Binding
Update and follow this specification for GRE encapsulation and GRE
keys exchange negotiation. If the received Proxy Binding
Acknowledgement has the TLV-header Format (T) flag set, the MAG MUST
use the TLV-header UDP based encapsulation format as shown in
Figure 5.
If the mobile access gateway sent a Proxy Binding Update with the GRE
key option included and the TLV-header Format (T) flag set and
received a successful Proxy Binding Acknowledgement with the GRE key
option included, the TLV-header Format (T) flag cleared, and the
status code <GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED>, the mobile
access gateway MUST NOT use GRE encapsulation for this mobility
session with UDP based tunneling. The mobile access gateway may
resend the Proxy Binding Update to negotiate different tunneling
options, e.g., using UDP based tunneling without GRE encapsulation if
possible or to de-register the the mobile node mobility session.
7.3.1. Sending and Receiving Data Packets
When the mobile access gateway is located in an IPv6-enabled network,
the mobile access gateway encapsulates and decapsulates IPv6 packets
as described in [RFC5213]. In this case, IPv4 payload traffic is
encapsulated in IPv6 packets before being sent to the local mobility
anchor as described in [ID-PMIP6-IPv4]. In addition, if the mobile
access gateway is located in an IPv4-only network and no UDP
tunneling format is used, the mobile access gateway encapsulates and
decapsulates IPv4 packets as described in [ID-PMIP6-IPv4]. IPv6
traffic is encapsulated in IPv4 packets following the procedure in
[ID-PMIP6-IPv4] before being sent to the local mobility anchor.
If the mobile access gateway have successfully negotiated GRE
encapsulation and GRE Keys as described in this specification for any
of the above cases, the mobile access gateway encapsulates or
decapsulates data packets following the same procedure while ensuring
that the GRE header is present as shown in Figure 7.
[IPv6-or-IPv4 Header]
[GRE Header]
[payload - IPv6-or-IPv4 Header]
Upper Layer protocols
Figure 7: IPv6-or-IPv4 over IPv4 Using Vanilla GRE Encapsulation
On the other hand, if the mobile access gateway is located in an
IPv4-only network where NAT has been detected on the path between the
MAG and the LMA and successfully negotiated GRE encapsulation and the
TLV-header format, the mobile access gateway MUST use UDP TLV-header
tunneling format when sending an IPv6 or IPv4 payload packet to the
LMA according to the format described in Figure 8.
IPv4 header (src=V4CoA, dst=HA_V4ADDR)
[UDP Header]
[TLV Header]
[GRE Header]
IPv6/v4 header (src=V6/V4HoA, dst=V6/V4CN)
Upper Layer protocols
Figure 8: IPv6-or-IPv4 over IPv4 Using TLV-header UDP Tunneling
7.4. Local Mobility Anchor Operation
When the local mobility anchor receives a Proxy Binding Update
encapsulated in UDP and containing the IPv4 home address option, it
needs to follow all the steps in [RFC5213] and [ID-PMIP6-IPv4]. In
addition, if the TLV-header Format (T) flag was set in the Proxy
Binding Update, the local mobility anchor needs to determine whether
it can accept the TLV-header UDP based encapsulation format. If it
does, it SHOULD set the TLV-header Format (T) flag in the Proxy
Binding Acknowledgement. Otherwise, the LMA MUST NOT set the TLV-
header Format (T) flag in the Proxy Binding Acknowledgement.
If the local mobility anchor receives a Proxy Binding Update with the
GRE Key option and TLV-header Format (T) flag set and based on a
policy check, the local mobility anchor determines that GRE
encapsulation is required BUT the LMA does NOT support TLV-header
tunneling and if PBU has been successfully processed, the LMA MUST
send a successful Proxy Binding Acknowledgement with the status code
<GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED>. This way, the local
mobility anchor indicates to the mobile access gateway that GRE
encapsulation and GRE keys have been successfully negotiated BUT GRE
encapsulation MUST NOT be used while TLV-header UDP based tunneling
format is not supported.
If the local mobility anchor and the mobile access gateway have
successfully negotiated the TLV-header UDP based tunneling format and
the GRE encapsulation for a specific mobility session, the local
mobility anchor processes data packets as described in the following
subsection.
7.4.1. Sending and Receiving Data Packets
The local mobility anchor follows the rules specified in [RFC5213]
for sending IPv6 payload packets to mobile nodes located in IPv6
through the mobile access gateway. When sending IPv4 packets to
mobile nodes in an IPv6 network, the local mobility anchor
encapsulates the IPv4 packets in IPv6 following the rules as
described in [ID-PMIP6-IPv4].
When sending IPv6 packets to a mobile node located in an IPv4
network, the local mobility anchor follows the format negotiated in
the Proxy Binding Update/Acknowledgement exchange as described in
[ID-PMIP6-IPv4]. In the case when TLV-tunneling format and the GRE
encapsulation for a specific mobility session have been successfully
negotiated between the local mobility anchor and the mobile access
gateway, the local mobility anchor follows the TLV-header UDP based
headers tunneling order as shown in Figure 8 when sending or
receiving tunnelled IPv4 or IPv6 payload packets to or from the
mobile access gateway, respectively.
7.5. Mobile Node Operation
This specification has no impact on IPv4 or IPv6 mobile nodes.
8. IANA Considerations
This specification defines a new Mobility Option, the GRE Key Option,
described in Section 6.1. This option is carried in the Mobility 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 needs to be 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 document also defines two new Binding Acknowledgement status This specification also defines three new Binding Acknowledgement
codes as described in Section 6.2 and requests that these two codes status codes as described in Section 6.4 and requests that these
be allocated with numeric values as specified in Section 6.2 from the three codes be allocated with numeric values as specified in
"Status Codes" registry of the Mobility IPv6 Parameters located at Section 6.4 from the "Status Codes" registry of the Mobility IPv6
Parameters located at
http://www.iana.org/assignments/mobility-parameters. http://www.iana.org/assignments/mobility-parameters.
8. Security Considerations 9. Security Considerations
The GRE Key Option, defined in this document, that can be carried in The GRE Key Option, defined in this specification, that can be
Proxy Binding Update and Proxy Binding Acknowledgement messages, carried in Proxy Binding Update and Proxy Binding Acknowledgement
reveals the group affiliation of a mobile node identified by its NAI messages, reveals the group affiliation of a mobile node identified
or an IP address. It may help an attacker in targeting flows by its NAI or an IP address. It may help an attacker in targeting
belonging to a specific group. This vulnerability can be prevented, flows belonging to a specific group. This vulnerability can be
by enabling confidentiality protection on the Proxy Binding Update prevented, by enabling confidentiality protection on the Proxy
and Proxy Binding Acknowledgement messages where the presence of the Binding Update and Proxy Binding Acknowledgement messages where the
NAI and GRE Key Options establish a mobile node's relation to a presence of the NAI and GRE Key Options establish a mobile node's
specific group. This vulnerability can also be avoided by enabling relation to a specific group. This vulnerability can also be avoided
confidentiality protection on all the tunneled data packets between by enabling confidentiality protection on all the tunneled data
the mobile access gateway and the local mobility anchor, for hiding packets between the mobile access gateway and the local mobility
all the markings. anchor, for hiding all the markings.
In Proxy Mobile IPv6 [RFC5213], the use of IPsec for protecting a In Proxy Mobile IPv6 [RFC5213], the use of IPsec [RFC4301] for
mobile node's data traffic is optional. However, if IPsec ESP is protecting a mobile node's data traffic is optional. Additionally,
used to protect the mobile node's tunneled data traffic where GRE Proxy Mobile IPv6 recommends the use of ESP in tunnel mode when using
encapsulation is used, GRE over IPsec is RECOMMENDED. ESP in protecting the mobile node's data traffic. However, when GRE
encapsulation is used, both IPsec tunnel mode and transport mode can
be used to protect the GRE header. The IPsec traffic selectors will
contain the protocol number for GRE, and there is currently no
mechanism to use the GRE key as a traffic selector.
9. 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 Langanier, 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.
10. Normative References 11. References
11.1. Normative References
[ID-DSMIP6]
Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", draft-ietf-mext-nemo-v4traversal-07 (work in
progress), December 2008.
[ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-11 (work in progress),
January 2009.
[ID-PMIP6-IPv4] [ID-PMIP6-IPv4]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09
(work in progress), January 2009. (work in progress), January 2009.
[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.
skipping to change at page 14, line 38 skipping to change at page 23, line 31
[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.
11.2. Informative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Authors' Addresses Authors' Addresses
Ahmad Muhanna Ahmad Muhanna
Nortel Nortel
2221 Lakeside Blvd. 2221 Lakeside Blvd.
Richardson, TX 75082 Richardson, TX 75082
USA USA
Email: amuhanna@nortel.com Email: amuhanna@nortel.com
Mohamed Khalil Mohamed Khalil
 End of changes. 66 change blocks. 
230 lines changed or deleted 597 lines changed or added

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