draft-ietf-netlmm-grekey-option-00.txt   draft-ietf-netlmm-grekey-option-01.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: February 26, 2009 S. Gundavelli Expires: April 10, 2009 S. Gundavelli
K. Leung K. Leung
Cisco Systems Cisco Systems
August 25, 2008 October 07, 2008
GRE Key Option for Proxy Mobile IPv6 GRE Key Option for Proxy Mobile IPv6
draft-ietf-netlmm-grekey-option-00.txt draft-ietf-netlmm-grekey-option-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 February 26, 2009. This Internet-Draft will expire on April 10, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Proxy Mobile IPv6 base specification and Proxy Mobile IPv6 This document defines a new Mobility Option for allowing the mobile
support for IPv4 allow the mobile node's IPv4 and IPv6 traffic access gateway and the local mobility anchor to negotiate GRE
between the local mobility anchor and the mobile access gateway to be encapsulation mode and exchange the downlink and uplink GRE keys
tunneled using IPv6 or IPv4 encapsulation headers. These which are used for marking the downlink and uplink traffic that
encapsulation modes do not offer the tunnel end-points the required belong to a specific mobile node session or a specific flow.
semantics to expose a service identifier that can be used to identify
traffic for a certain classification, such as for supporting mobile
nodes that are using overlapping private IPv4 addressing. The
extension defined in this document allow the mobile access gateway
and the local mobility anchor to negotiate GRE encapsulation mode and
exchange the GRE keys for marking the flows, so tunnel peers can
process individual flows differently.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. GRE Encapsulation and Key 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 Support . . . . . . . . . . . . . . . . 6 3.2. GRE Encapsulation Support . . . . . . . . . . . . . . . . 6
skipping to change at page 2, line 33 skipping to change at page 2, line 26
3.3.2. GRE Key Exchange During Binding Re-registration . . . 6 3.3.2. GRE Key Exchange During Binding Re-registration . . . 6
4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 7 4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 7
4.1. Extensions to the Conceptual Data Structure . . . . . . . 7 4.1. Extensions to the Conceptual Data Structure . . . . . . . 7
4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 8 4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 8
5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 9 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 9
5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 9 5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 9
5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 10 5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 10
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 11 6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 10. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
The base Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile The base Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile
IPv6 support for IPv4 [ID-PMIP6-IPv4] allow the use of IPv6 and IPv4 IPv6 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 flow. Thus, there is a need for an encapsulation mode with
richer semantics. The Generic Routing Encapsulation [RFC2784] and richer semantics. The Generic Routing Encapsulation [RFC2784] and
the Key extension as defined in [RFC2890], has the required semantics the Key extension as defined in [RFC2890], has the required semantics
to allow such distinction for use in Proxy Mobile IPv6. to allow such distinction for use in Proxy Mobile IPv6.
This document defines a new Mobility Option for allowing the MAG and This document defines the GRE Key option to be used for the
the LMA to negotiate GRE encapsulation mode and exchange the downlink negotiation of GRE encapsulation mode and the exchange of the uplink
and uplink GRE keys that can be used for marking the downlink and and downlink GRE keys. The negotiated downlink and uplink GRE keys
uplink traffic which belong to a specific mobile node session or a can be used for marking the downlink and uplink traffic for a
specific flow. specific mobile node session or a specific flow.
2. Conventions & Terminology 2. Conventions & Terminology
2.1. Conventions 2.1. Conventions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "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 [RFC2119]. document 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 specification [RFC3775] and
Proxy Mobile IPv6 specification [RFC5213]. The following terms are Proxy Mobile IPv6 specification [RFC5213]. The following terms are
used in this document. used in this document.
Downlink Traffic Downlink Traffic
skipping to change at page 4, line 23 skipping to change at page 4, line 23
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 mobile node session or flow as described in this to a specific mobile node session or flow as described in this
document. document.
3. GRE Encapsulation and Key Exchange 3. GRE Encapsulation and Key Exchange
3.1. GRE Encapsulation Overview 3.1. GRE Encapsulation Overview
Using the extension defined in this specification, the mobile access Using the GRE Key option defined in this specification, the mobile
gateway and the local mobility anchor can negotiate GRE encapsulation access gateway and the local mobility anchor can negotiate GRE
mode and exchange the GRE keys for marking the downlink and uplink encapsulation mode and exchange the GRE keys for marking the downlink
traffic. and uplink traffic.
Once the GRE keys have been exchanged between the mobile access Once the GRE keys have been exchanged between the mobile access
gateway and the local mobility anchor, the mobile access gateway will gateway and the local mobility anchor, the mobile access gateway will
use the uplink GRE key that is assigned by the local mobility anchor use the uplink GRE key that is assigned by the local mobility anchor
in the GRE encapsulation header of the uplink payload packet. in the GRE encapsulation header of the uplink payload packet.
Similarly, the local mobility anchor will use the downlink GRE key as Similarly, the local mobility anchor will use the downlink GRE key as
negotiated with the mobile access gateway in the GRE encapsulation negotiated with the mobile access gateway in the GRE encapsulation
header of the downlink payload packet. 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
skipping to change at page 6, line 8 skipping to change at page 6, line 8
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 packet, and route them accordingly. tunneled packet, and route them accordingly.
3.2. GRE Encapsulation Support 3.2. GRE Encapsulation Support
To request GRE encapsulation support without exchanging the GRE keys, To request GRE encapsulation support without exchanging the GRE keys,
the mobile access gateway MUST include the GRE Key Option in the the mobile access gateway MUST include the GRE Key option in the
Proxy Binding Update message sent to the local mobility anchor. The Proxy Binding Update message sent to the local mobility anchor. The
mobile access gateway MUST set the length field of the GRE Key option mobile access gateway MUST set the length field of the GRE Key option
to 2 octets. to 2 octets.
If the local mobility anchor supports GRE encapsulation and after If the local mobility anchor supports GRE encapsulation and after
successfully processes the Proxy Binding Update, the LMA sends a successfully processes the Proxy Binding Update, the LMA sends a
Proxy Binding Acknowledgement and MUST include the GRE Key option Proxy Binding Acknowledgement and MUST include the GRE Key option
with the length field set to 2 octets. with the length field set to 2 octets.
However, If the local mobility anchor does not support GRE
encapsulation, the LMA MUST reject the Proxy Binding Update by
sending a Proxy Binding Acknowledgement message with the status field
is set to <IANA-TBA1> as defined in Section 6.2.
3.3. GRE Key Exchange Mechanism 3.3. GRE Key Exchange Mechanism
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 exchange downlink and uplink GRE keys using
proxy mobile IPv6 registration procedure. 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 is peer agreement, that GRE encapsulation is needed and GRE keys is
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 processes the initial PBU and accepting the After successfully processes the initial Proxy Binding Update and
downlink GRE key, the LMA MUST include the GRE Key option with the accepting the downlink GRE key, the LMA MUST include the GRE Key
uplink GRE key in the GRE Key Identifier field when sending a option with the uplink GRE key in the GRE Key Identifier field when
successful PBA to the MAG. sending a successful Proxy Binding Acknowledgement 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 binding, the MAG SHOULD NOT include
the GRE Key option with the downlink GRE key in the Proxy Binding the GRE Key option with the downlink GRE key in the Proxy Binding
Update which is used for requesting a Binding Lifetime Extension. 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 MAG MUST include the GRE key option with the required, the new mobile access gateway MUST include the GRE key
downlink GRE key in the Proxy Binding Update which is used for option with the downlink GRE key in the Proxy Binding Update which is
requesting an after handoff Binding Lifetime extension. In this used for requesting an after handoff Binding Lifetime extension. In
case, the downlink GRE key may be identical to the downlink GRE key this case, the new MAG may either pick a new downlink GRE key or use
that the previous MAG has exchanged with the LMA for the the same the downlink GRE key that was used by the previous MAG for the same
binding. binding. For the new MAG to know the downlink GRE key used by the
previous MAG, it may require transfer of context from the previous
MAG to the new MAG during a handover. Such mechanisms are out-of-
scope for this document.
If the LMA successfully processes an after handoff Binding Lifetime If the LMA successfully processes a handoff-triggered Binding
extension PBU message which contains a GRE key option with a downlink Lifetime Extension Proxy Binding Update message which contains a GRE
GRE key included, the LMA MUST return the same uplink GRE key that key option with a downlink GRE key included, the LMA MUST return the
was exchanged with the previous MAG and is saved in the respected same uplink GRE key that was exchanged with the previous MAG and is
BCE. saved in the respected BCE.
If the LMA receives an after handoff Binding Lifetime extension PBU If the LMA receives handoff-triggered Binding Lifetime Extension
message without the GRE key option for a BCE that is using GRE keys Proxy Binding Update message without the GRE key option for a BCE
and GRE encapsulation, the LMA MUST reject the Proxy Binding Update that is using GRE keys and GRE encapsulation, the LMA MUST reject the
by sending a Proxy Binding Acknowledgement message with the status Proxy Binding Update by sending a Proxy Binding Acknowledgement
field is set to <IANA-TBA2> as defined in Section 6.2. message with the status field is set to <GRE KEY OPTION REQUIRED> as
defined in Section 6.2.
If the LMA receives a no handoff Binding Lifetime extension PBU If the LMA receives a no handoff Binding Lifetime extension Proxy
message with the GRE key option and the downlink GRE key included Binding Update message with the GRE key option and the downlink GRE
from the same MAG that is currently hosting the respected binding key included from the same MAG that is currently hosting the
current pCoA, the LMA MUST NOT reject the PBU because of the GRE key respected binding current pCoA, the LMA MUST NOT reject the Proxy
option being included in a binding reregistration PBU message. In Binding Update because of the GRE key option being included in a
this case, the LMA processes the PBU normally and if the included binding reregistration Proxy Binding Update message. In this case,
downlink GRE key is different than the one saved in the respected the LMA processes the Proxy Binding Update normally and if the
BCE, the LMA MUST update the BCE with the new downlink GRE key. 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 entry for Every mobile access gateway maintains a Binding Update List entry for
each currently attached mobile node, as explained in Section 6.1 of each currently attached mobile node, as explained in Section 6.1 of
the Proxy Mobile IPv6 specification [RFC5213]. To support this the Proxy Mobile IPv6 specification [RFC5213]. To support this
specification, the conceptual Binding Update List entry data specification, the conceptual Binding Update List entry data
structure must be extended with the following three new additional structure must be extended with the following three new additional
fields. 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 used in the GRE encapsulation header of the o The Downlink GRE Key used in the GRE encapsulation header of the
tunneled packet from the local mobility anchor to the mobile tunneled packet from the local mobility anchor to the mobile
access gateway that is destined to the mobile node. This GRE Key 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 PBU message. 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 packet from the mobile access gateway to the local tunneled packet from the mobile access gateway to the local
mobility anchor that is originating from the mobile node. This mobility anchor that is originating from the mobile node. This
GRE Key is obtained from the GRE Key Identifier field of the GRE GRE Key is obtained from the GRE Key Identifier field of the GRE
Key option present in the received PBA message sent by the LMA as Key option present in the received Proxy Binding Acknowledgement
specified in this document. message sent by the LMA as specified in this document.
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 and GRE key is
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 by the mobile access gateway
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 which includes the uplink GRE key, the
mobile access gateway MUST update the related three fields in the mobile access gateway MUST update the related three fields in the
mobile node Binding Update List entry described in Section 4.1. mobile node Binding Update List entry described in Section 4.1.
Additionally, the MAG MUST use the assigned uplink GRE Key for Additionally, the MAG MUST use the assigned uplink GRE Key for
tunneling all the traffic originating from the mobile node before tunneling all the traffic originating from the mobile node before
forwarding the tunneled traffic to the LMA. forwarding the tunneled traffic to the LMA.
o For a given mobile node, if the local mobility anchor rejects the o If the mobile access gateway included the GRE Key option in the
Proxy Binding Update by sending a Proxy Binding Acknowledgement Proxy Binding Update for a specific mobile node and the local
with the status code <IANA-TBA1> (GRE Encapsulation NOT mobility anchor accepts the Proxy Binding Update by sending a
supported), the mobile access gateway MUST NOT include the GRE Key Proxy Binding Acknowledgement with a status code <SUCCESS> or any
Option in the subsequent Proxy Binding Update messages that are status code that is less than 128 other than <GRE KEY OPTION NOT
sent to that LMA. REQUIRED>, the mobile access gateway MUST consider that the local
mobility anchor does not support GRE Key option as per this
specification. The mobile access gateway SHOULD NOT include the
GRE Key option in any subsequent Proxy Binding Update message that
is sent to that LMA.
o If the mobile access gateway sent a Proxy Binding Update message 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 <IANA-TBA2>, indicating that Acknowledgement has the Status Code <GRE KEY OPTION REQUIRED>,
the GRE encapsulation and GRE key is required, the mobile access indicating that the GRE encapsulation and GRE key is required, the
gateway SHOULD resend the Proxy Binding Update message with the mobile access gateway SHOULD resend the Proxy Binding Update
GRE Key Option. If the MAG does not support GRE encapsulation and 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 PBA message without the GRE key option, the received a successful Proxy Binding Acknowledgement message with a
mobile access gateway MUST consider that GRE encapsulation and GRE status code <GRE KEY OPTION NOT REQUIRED>, the mobile access
keys is not required for this specific binding. The MAG follows gateway MUST consider that GRE encapsulation and GRE keys is not
the Proxy Mobile IPv6 specification [RFC5213] for the handling of required for this specific binding. The MAG follows the Proxy
uplink and downlink traffic for this mobile node binding. Mobile IPv6 specification [RFC5213] for the handling of uplink and
downlink traffic for this mobile node binding and MUST NOT include
the GRE Key option in any subsequent Proxy Binding Update message
for this specific mobile node that are sent to that LMA.
o If the MAG sent a re-registration PBU message without the GRE Key o If the MAG sent a re-registration Proxy Binding Update message
Option, but received a successful PBA which includes the GRE Key without the GRE Key option, but received a successful Proxy
option with the uplink GRE key, the MAG MUST compare the received Binding Acknowledgement which includes the GRE Key option with the
uplink GRE key with the one saved in the respected Binding Update uplink GRE key, the MAG MUST compare the received uplink GRE key
List entry and update it if the received uplink GRE key is with the one saved in the respected Binding Update List entry and
different. 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 and exchanged the initial
GRE keys with the LMA for a specific binding, the MAG SHOULD NOT GRE keys with the LMA for a specific binding, the MAG SHOULD NOT
include the GRE Key option in the de-registration Proxy Binding include the GRE Key option in the de-registration Proxy Binding
Update. Update.
o On receiving a packet from the tunnel with the GRE encapsulation o On receiving a packet from the tunnel with the GRE encapsulation
header, the mobile access gateway MUST use the GRE Key to header, the mobile access gateway MUST use the GRE Key to
determine the necessary special processing for the data packet, determine the necessary special processing for the data packet,
e.g., lookup the mobile node's layer-2 address, determine any e.g., lookup the mobile node's layer-2 address, determine any
skipping to change at page 10, line 7 skipping to change at page 10, line 15
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 packet from the local encapsulation header of the tunneled 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 packet from the mobile access encapsulation header of the tunneled packet from the mobile access
gateway to the local mobility anchor. gateway to the local mobility anchor.
5.2. Operational Summary 5.2. Operational Summary
o Upon receiving a Proxy Binding Update message with the GRE Key
Option and if the local mobility anchor does not support GRE
encapsulation mode, the LMA MUST send a Proxy Binding
Acknowledgement message to the MAG with a status code <IANA-TBA1>
as defined in Section 6.2.
o After successfully processes a Proxy Binding Update message with o After successfully processes a Proxy Binding Update message with
the GRE Key Option which includes a downlink GRE key in the GRE the GRE Key option which includes a downlink GRE key in the GRE
Key Identifier field for Initial GRE Key exchange as in Key Identifier field for Initial GRE Key exchange as in
Section 3.3.1, the local mobility anchor MUST include the GRE Key Section 3.3.1, the local mobility anchor MUST include the GRE Key
option with the uplink GRE key in the GRE Key Identifier field option with the uplink GRE key in the GRE Key Identifier field
when responding with a successful PBA message. 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 binding, the local mobility
anchor MUST use the negotiated downlink GRE key in the GRE header anchor MUST use the negotiated downlink GRE key in the GRE header
of every packet that is destined to the mobile node of this of every packet that is destined to the mobile node of this
specific binding over the GRE tunnel to the mobile access gateway. 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 determines that
GRE encapsulation and GRE key is required, e.g., overlapping IPv4 GRE encapsulation and GRE key is required, e.g., overlapping IPv4
private addressing is in use, LMA local policy or LMA-MAG peer private addressing is in use, LMA local policy or LMA-MAG peer
policy, the local mobility anchor MUST reject the request and send policy, the local mobility anchor MUST reject the request and send
the Proxy Binding Acknowledgement message to the mobile access the Proxy Binding Acknowledgement message to the mobile access
gateway with the status code <IANA-TBA2> as defined in gateway with the status code <GRE KEY OPTION REQUIRED> as defined
Section 6.2, indicating that GRE encapsulation and GRE key is in Section 6.2, indicating that GRE encapsulation and GRE key is
required. required.
o If after receiving Proxy Binding Update message with the GRE Key o If after receiving Proxy Binding Update message with the GRE Key
Option and successfully processes the PBU, the local mobility option and successfully processes the Proxy Binding Update, the
anchor determines that GRE encapsulation and key exchange is not local mobility anchor determines that GRE encapsulation and key
required for this specific binding, e.g., private IPv4 addressing exchange is not required for this specific binding, e.g., private
is not in use, the LMA MUST send a Proxy Binding Acknowledgement IPv4 addressing is not in use, the LMA MUST send a Proxy Binding
message to the MAG with the status code success without including Acknowledgement message to the MAG with the status code <GRE KEY
OPTION NOT REQUIRED>. The local mobility anchor MUST NOT include
the GRE Key option. the GRE Key option.
o If the local mobility anchor successfully processes a o If the local mobility anchor successfully processes a
deregistration PBU message which contains a GRE Encapsulation deregistration Proxy Binding Update message which contains a GRE
option with a downlink GRE key included, the LMA follows the same Key option with a downlink GRE key included, the LMA follows the
deregistration process as per the base Proxy Mobile IPv6 same deregistration 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 encapsulation
header, the local mobility anchor MUST use the GRE Key present in header, the local mobility anchor MUST use the GRE Key present in
the GRE extension header to determine the necessary special the GRE extension header to determine the necessary special
processing for the data packet, e.g., lookup the mobile node's processing for the data packet, e.g., lookup the mobile node's
home gateway address, determine any special processing or home gateway address, determine any special processing or
treatment for the data packet flow, then remove the encapsulation treatment for the data packet flow, then remove the encapsulation
header before forwarding the packet. 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 for supporting the GRE tunneling and GRE Key protocol messages for supporting the GRE tunneling and GRE Key
exchange for Proxy Mobile IPv6. exchange for Proxy Mobile IPv6.
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
and exchanging the downlink and uplink GRE keys to be used by the mode and exchanging the downlink and uplink GRE keys that can be used
peers on all GRE encapsulated packets for the specified mobile node by the peers in all GRE encapsulated packets for marking that
binding or flow. specific mobile node's data flow.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key Identifier | | GRE Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 15 skipping to change at page 12, line 20
that either the downlink or the uplink GRE key is carried. that either the downlink or the uplink GRE 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 32-bit field containing the Downlink or the Uplink GRE Key. This
field is present in the GRE Key mobility option only if the GRE field is present in the GRE Key option only if the GRE keys are
keys are being exchanged using the PBU and PBA messages. being exchanged using the Proxy Binding Update and Proxy Binding
Acknowledgement messages.
6.2. Status Codes 6.2. 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.
TBA1: GRE Encapsulation not required. GRE KEY OPTION NOT REQUIRED (TBD less than 128)
TBA2: GRE Encapsulation and GRE Key option required. When the local mobility anchor receives a Proxy Binding Update
with the GRE Key option while the GRE encapsulation is not
required for this specific mobile node, the LMA uses this code to
indicate to the mobile access gateway that the Proxy Binding
Update has been processed successfully but GRE Encapsulation and
GRE Key is not required.
GRE KEY OPTION REQUIRED (TBD more than 128)
When the local mobility anchor receives a Proxy Binding Update
without the GRE Key option while the GRE encapsulation is required
for this specific mobile node, the local mobility anchor uses this
code to reject the Proxy Binding Update and indicate to the mobile
access gateway that GRE Encapsulation and Keys is required.
7. IANA Considerations 7. IANA Considerations
This document defines a new Mobility Option, the GRE Key Option, This document 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 document also defines two new Binding Acknowledgement status
codes TBA1 and TBA2 as described in Section 6.2. This document codes as described in Section 6.2 and requests that these two codes
requests that these two codes be allocated from the "Status Codes" be allocated with numeric values as specified in Section 6.2 from the
registry of the Mobility IPv6 Parameters located at "Status Codes" registry of the Mobility IPv6 Parameters located at
http://www.iana.org/assignments/mobility-parameters and that the http://www.iana.org/assignments/mobility-parameters.
numeric value of these codes be greater than 128.
8. Security Considerations 8. Security Considerations
The GRE Key Option, defined in this document, that can be carried in The GRE Key Option, defined in this document, that can be carried in
Proxy Binding Update and Proxy Binding Acknowledgement messages, Proxy Binding Update and Proxy Binding Acknowledgement messages,
reveals the group affiliation of a mobile node identified by its NAI reveals the group affiliation of a mobile node identified by its NAI
or an IP address. It may help an attacker in targeting flows or an IP address. It may help an attacker in targeting flows
belonging to a specific group. This vulnerability can be prevented, belonging to a specific group. This vulnerability can be prevented,
by enabling confidentiality protection on the Proxy Binding Update by enabling confidentiality protection on the Proxy Binding Update
and Acknowledgement messages where the presence of the NAI and GRE and Proxy Binding Acknowledgement messages where the presence of the
Key Options establish a mobile node's relation to a specific group. NAI and GRE Key Options establish a mobile node's relation to a
This vulnerability can also be avoided by enabling confidentiality specific group. This vulnerability can also be avoided by enabling
protection on all the tunneled data packets between the mobile access confidentiality protection on all the tunneled data packets between
gateway and the local mobility anchor, for hiding all the markings. the mobile access gateway and the local mobility anchor, for hiding
all the markings.
9. Acknowledgements 9. 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 Langanier, 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 10. Normative References
[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-03 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-05
(work in progress), May 2008. (work in progress), September 2008.
[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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 40 change blocks. 
131 lines changed or deleted 142 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/