draft-ietf-netlmm-grekey-option-02.txt   draft-ietf-netlmm-grekey-option-03.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: May 25, 2009 S. Gundavelli Expires: August 1, 2009 S. Gundavelli
K. Leung K. Leung
Cisco Systems Cisco Systems
November 21, 2008 January 28, 2009
GRE Key Option for Proxy Mobile IPv6 GRE Key Option for Proxy Mobile IPv6
draft-ietf-netlmm-grekey-option-02.txt draft-ietf-netlmm-grekey-option-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 May 25, 2009. This Internet-Draft will expire on August 1, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document defines a new Mobility Option for allowing the mobile This document defines a new Mobility Option for allowing the mobile
access gateway and the local mobility anchor to negotiate GRE access gateway and the local mobility anchor to negotiate GRE
encapsulation mode and exchange the downlink and uplink GRE keys encapsulation mode and exchange the downlink and uplink GRE keys
which are used for marking the downlink and uplink traffic that which are used for marking the downlink and uplink traffic that
belong to a specific mobile node session or a specific flow. belong to a specific mobile node session or a specific flow.
Table of Contents Table of Contents
skipping to change at page 2, line 29 skipping to change at page 2, line 37
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 . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 10. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
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 the GRE Key option to be used for the This document 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 the exchange of the uplink
and downlink GRE keys. The negotiated downlink and uplink GRE keys and downlink GRE keys. The negotiated downlink and uplink GRE keys
can be used for marking the downlink and uplink traffic for a can be used for marking the downlink and uplink traffic for a
specific mobile node session or a specific flow. specific mobility session or a specific flow.
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]. document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Terminology 2.2. Terminology
skipping to change at page 4, line 9 skipping to change at page 4, line 9
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 mobile node session or flow as described in belongs to a specific mobility session or flow as described in
this document. this document.
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 mobile node session or flow as described in this to a specific mobility 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 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 and exchange the GRE keys for marking the downlink
and uplink traffic. and uplink traffic.
skipping to change at page 5, line 46 skipping to change at page 5, line 46
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 packet, and route them accordingly. tunneled payload 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, the mobile access gateway MUST
the mobile access gateway MUST include the GRE Key option in the include the GRE Key option in the Proxy Binding Update message sent
Proxy Binding Update message sent to the local mobility anchor. The to the local mobility anchor. In case, the mobile access gateway
mobile access gateway MUST set the length field of the GRE Key option wants to use GRE encapsulation without the GRE keys, it MUST NOT
to 2 octets. include the GRE Key Identifier in the option.
If the local mobility anchor supports GRE encapsulation and after If the local mobility anchor supports GRE encapsulation and the Proxy
successfully processes the Proxy Binding Update, the LMA sends a Binding Update processing is successful, the LMA sends a Proxy
Proxy Binding Acknowledgement and MUST include the GRE Key option Binding Acknowledgement with the GRE Key option. If GRE
with the length field set to 2 octets. encapsulation is being used without the GRE keys, the LMA MUST NOT
include the GRE Key Identifier in the GRE option.
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 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 processes the initial Proxy Binding Update and After successfully processing the initial Proxy Binding Update and
accepting the downlink GRE key, the LMA MUST include the GRE Key accepting the downlink GRE key, the LMA MUST include the GRE Key
option with the uplink GRE key in the GRE Key Identifier field when option with the uplink GRE key in the GRE Key Identifier field when
sending a successful Proxy Binding Acknowledgement 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.
skipping to change at page 7, line 8 skipping to change at page 7, line 9
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 handover. 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 document.
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 BCE. saved in the respected Binding Cache Entry (BCE).
If the LMA receives handoff-triggered Binding Lifetime Extension If the LMA receives 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 MUST reject the
Proxy Binding Update by sending a Proxy Binding Acknowledgement Proxy Binding Update by sending a Proxy Binding Acknowledgement
message with the status field is set to <GRE KEY OPTION REQUIRED> as message with the status field is set to <GRE KEY OPTION REQUIRED> as
defined in Section 6.2. defined in Section 6.2. If the LMA is preconfigured to use a
different mechanism other than GRE encapsulation with the MAG which
sent the handoff-triggered Binding Lifetime Extension Proxy Binding
Update, the LMA MAY accept the PBU and if it is successfully
processed, the LMA returns a successful PBA without the GRE Key
option. In this case, mapping between the current GRE keys and the
other mechanism identifiers or labels is outside the scope of this
specification.
If the LMA receives a no handoff Binding Lifetime extension Proxy Typically, the MAG does not include the GRE Key Option in a Proxy
Binding Update message with the GRE key option and the downlink GRE Binding Update message sent to refresh an existing binding. However,
key included from the same MAG that is currently hosting the if the LMA receives a Proxy Binding Update from the current MAG to
respected binding current pCoA, the LMA MUST NOT reject the Proxy extend the existing binding, and the Proxy Binding Update messages
Binding Update because of the GRE key option being included in a contains the GRE Key option and the downlink GRE Key identifier, it
binding reregistration Proxy Binding Update message. In this case, MUST NOT reject the Proxy Binding Update message. In this case, the
the LMA processes the Proxy Binding Update normally and if the LMA processes the Proxy Binding Update normally and if the included
included downlink GRE key is different than the one saved in the downlink GRE key is different than the one saved in the respected
respected BCE, the LMA MUST update the BCE with the new downlink GRE BCE, the LMA MUST update the BCE with the new downlink GRE key.
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 (BUL)
each currently attached mobile node, as explained in Section 6.1 of entry for each currently attached mobile node, as explained in
the Proxy Mobile IPv6 specification [RFC5213]. To support this Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213]. To
specification, the conceptual Binding Update List entry data support this specification, the conceptual Binding Update List entry
structure must be extended with the following three new additional data structure must be extended with the following three new
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 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 payload packet from the local mobility anchor to the
access gateway that is destined to the mobile node. This GRE Key mobile access gateway that is destined to the mobile node. This
is generated by the MAG and communicated to the LMA in the GRE Key GRE key is generated by the MAG and communicated to the LMA in the
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 packet from the mobile access gateway to the local tunneled payload packet from the mobile access gateway to the
mobility anchor that is originating from the mobile node. This local mobility anchor that is originating from the mobile node.
GRE Key is obtained from the GRE Key Identifier field of the GRE This GRE key is obtained from the GRE Key Identifier field of the
Key option present in the received Proxy Binding Acknowledgement GRE Key option present in the received Proxy Binding
message sent by the LMA as specified in this document. Acknowledgement 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
skipping to change at page 10, line 5 skipping to change at page 10, line 12
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 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 packet from the mobile access encapsulation header of the tunneled payload packet from the
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 processes a Proxy Binding Update message with o After successfully processing 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 Proxy Binding Acknowledgement when responding with a successful Proxy Binding Acknowledgement
message. 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
skipping to change at page 10, line 47 skipping to change at page 11, line 6
in 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 Proxy Binding Update, the option and successfully processes the Proxy Binding Update, the
local mobility anchor determines that GRE encapsulation and key local mobility anchor determines that GRE encapsulation and key
exchange is not required for this specific binding, e.g., private exchange is 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 Proxy Binding
Acknowledgement message to the MAG with the status code <GRE KEY Acknowledgement message to the MAG with the status code <GRE KEY
OPTION NOT REQUIRED>. The local mobility anchor MUST NOT include OPTION NOT REQUIRED>. The local mobility anchor MUST NOT include
the GRE Key option. the GRE Key option in that Proxy Binding Acknowledgement.
o If the local mobility anchor successfully processes a o If the local mobility anchor successfully processes a de-
deregistration Proxy Binding Update message which contains a GRE registration Proxy Binding Update message which contains a GRE Key
Key option with a downlink GRE key included, the LMA follows the option with a downlink GRE key included, the LMA follows the same
same deregistration process as per the base 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 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.
skipping to change at page 12, line 19 skipping to change at page 12, line 25
the option. If the length field is set to a value of 6, it means 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. 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 option only if the GRE keys are field is present in the GRE Key option only if the GRE keys are
being exchanged using the Proxy Binding Update and Proxy Binding being exchanged using the Proxy Binding Update and Proxy Binding
Acknowledgement messages. 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.
GRE KEY OPTION NOT REQUIRED (TBD less than 128) GRE KEY OPTION NOT REQUIRED (TBD less than 128)
skipping to change at page 13, line 34 skipping to change at page 13, line 34
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 Proxy Binding Acknowledgement messages where the presence of the and Proxy Binding Acknowledgement messages where the presence of the
NAI and GRE Key Options establish a mobile node's relation to a NAI and GRE Key Options establish a mobile node's relation to a
specific group. This vulnerability can also be avoided by enabling specific group. This vulnerability can also be avoided by enabling
confidentiality protection on all the tunneled data packets between confidentiality protection on all the tunneled data packets between
the mobile access gateway and the local mobility anchor, for hiding the mobile access gateway and the local mobility anchor, for hiding
all the markings. all the markings.
In Proxy Mobile IPv6 [RFC5213], the use of IPsec for protecting a
mobile node's data traffic is optional. However, if IPsec ESP is
used to protect the mobile node's tunneled data traffic where GRE
encapsulation is used, GRE over IPsec is RECOMMENDED.
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-05 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09
(work in progress), September 2008. (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.
[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.
skipping to change at page 16, line 4 skipping to change at line 646
Email: sgundave@cisco.com Email: sgundave@cisco.com
Kent Leung Kent Leung
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: kleung@cisco.com Email: kleung@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 33 change blocks. 
70 lines changed or deleted 88 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/