draft-ietf-netlmm-grekey-option-04.txt   draft-ietf-netlmm-grekey-option-05.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 20, 2009 S. Gundavelli Expires: August 22, 2009 S. Gundavelli
K. Leung K. Leung
Cisco Systems Cisco Systems
February 16, 2009 February 18, 2009
GRE Key Option for Proxy Mobile IPv6 GRE Key Option for Proxy Mobile IPv6
draft-ietf-netlmm-grekey-option-04.txt draft-ietf-netlmm-grekey-option-05.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 20, 2009. This Internet-Draft will expire on August 22, 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 7 3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 7
3.3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . 7 3.3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . 7
3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 7 3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 7
3.3.2. GRE Key Exchange During Binding Re-registration . . . 8 3.3.2. GRE Key Exchange During Binding Re-registration . . . 8
4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 9 4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 9
4.1. Extensions to the Conceptual Data Structure . . . . . . . 9 4.1. Extensions to the Conceptual Data Structure . . . . . . . 9
4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 9 4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 9
5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 11 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 11
5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 11 5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 11
5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 11 5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 11
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 13 6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Proxy Binding Update Message Extension . . . . . . . . . . 14 6.2. Proxy Binding Update Message Extension . . . . . . . . . . 14
6.3. Proxy Binding Acknowledgement Message Extension . . . . . 14 6.3. Proxy Binding Acknowledgement Message Extension . . . . . 14
6.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 15
7. Data Packets Processing Considerations . . . . . . . . . . . . 16 7. Data Packets Processing Considerations . . . . . . . . . . . . 15
7.1. Tunneling Format . . . . . . . . . . . . . . . . . . . . . 16 7.1. Tunneling Format . . . . . . . . . . . . . . . . . . . . . 16
7.2. TLV-header Tunneling Negotiation . . . . . . . . . . . . . 17 7.2. TLV-header Tunneling Negotiation . . . . . . . . . . . . . 17
7.3. Mobile Access Gateway Operation . . . . . . . . . . . . . 18 7.3. Mobile Access Gateway Operation . . . . . . . . . . . . . 18
7.3.1. Sending and Receiving Data Packets . . . . . . . . . . 19 7.3.1. Sending and Receiving Data Packets . . . . . . . . . . 19
7.4. Local Mobility Anchor Operation . . . . . . . . . . . . . 20 7.4. Local Mobility Anchor Operation . . . . . . . . . . . . . 20
7.4.1. Sending and Receiving Data Packets . . . . . . . . . . 21 7.4.1. Sending and Receiving Data Packets . . . . . . . . . . 21
7.5. Mobile Node Operation . . . . . . . . . . . . . . . . . . 21 7.5. Mobile Node Operation . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile IPv6 Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile 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
skipping to change at page 4, line 25 skipping to change at page 4, line 25
[RFC2784] and the Key extension as defined in [RFC2890], has the [RFC2784] and the Key extension as defined in [RFC2890], has the
required semantics to allow such distinction for use in Proxy Mobile required semantics to allow such distinction for use in Proxy Mobile
IPv6. IPv6.
This specification defines the GRE Key option to be used for the This specification defines the GRE Key option to be used for the
negotiation of GRE encapsulation mode and exchange of the uplink and negotiation of GRE encapsulation mode and exchange of the uplink and
downlink GRE keys. The negotiated downlink and uplink GRE keys can downlink GRE keys. The negotiated downlink and uplink GRE keys can
be used for marking the downlink and uplink traffic for a specific be used for marking the downlink and uplink traffic for a specific
mobility session. In addition, this specification enables the mobile mobility session. In addition, this specification enables the mobile
access gateway and the local mobility anchor to explicitly negotiate access gateway and the local mobility anchor to explicitly negotiate
the GRE encapsulation mode only using a special flag in the GRE Key the GRE encapsulation mode only using the GRE Key mobility option
mobility option. while omitting the GRE Key Identifier field. .
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
specification are to be interpreted as described in RFC 2119 specification are to be interpreted as described in RFC 2119
[RFC2119]. [RFC2119].
skipping to change at page 5, line 43 skipping to change at page 5, line 43
3. GRE Encapsulation and Keys Exchange 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 only or GRE encapsulation mode and exchange the encapsulation mode only or GRE encapsulation mode and exchange the
GRE keys for marking the downlink and uplink traffics. In the case GRE keys for marking the downlink and uplink traffics. In the case
when GRE encapsulation mode only is negotiated between the MAG and when GRE encapsulation mode only is negotiated between the MAG and
LMA, the mechanism used to exchange or deliver these GRE keys, if the LMA, then no GRE keys are used.
used, to the MAG and LMA is out-of scope of this specification.
However, once the GRE keys have been exchanged between the mobile However, once the GRE keys have been exchanged between the mobile
access gateway and the local mobility anchor as per this access gateway and the local mobility anchor as per this
specification, the mobile access gateway will use the uplink GRE key specification, the mobile access gateway will use the uplink GRE key
that is assigned by the local mobility anchor in the GRE header of that is assigned by the local mobility anchor in the GRE header of
the uplink payload packet. Similarly, the local mobility anchor will the uplink payload packet. Similarly, the local mobility anchor will
use the downlink GRE key as negotiated with the mobile access gateway use the downlink GRE key as negotiated with the mobile access gateway
in the GRE 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
skipping to change at page 7, line 20 skipping to change at page 7, line 18
tunneled payload packet, and route them accordingly. However, the tunneled payload packet, and route them accordingly. However, the
GRE keys as in this specification apply to the individual mobility GRE keys as in this specification apply to the individual mobility
binding updated by the Proxy Binding Update but not to all bindings binding updated by the Proxy Binding Update but not to all bindings
that the mobile may have registered following procedures described in that the mobile may have registered following procedures described in
[ID-MCoA]. [ID-MCoA].
3.2. GRE Encapsulation Mode Only 3.2. GRE Encapsulation Mode Only
In order for the mobile access gateway to request GRE encapsulation In order for the mobile access gateway to request GRE encapsulation
mode only without exchanging the GRE keys, the mobile access gateway mode only without exchanging the GRE keys, the mobile access gateway
MUST include the GRE Key option in the Proxy Binding Update with the MUST include the GRE Key option but omit the GRE Key Identifier field
Key NOT Used (K) bit set. In this case, the MAG MAY set the GRE Key in the Proxy Binding Update.
Identifier field to any value including zero.
If the local mobility anchor supports GRE encapsulation and the If the local mobility anchor supports GRE encapsulation and the
received Proxy Binding Update contains the GRE Key option with the received Proxy Binding Update contains the GRE Key option but the GRE
Key NOT Used (K) bit set, the mobile access gateway is requesting GRE Key Identifier field is omitted, the mobile access gateway is
encapsulation without exchanging the GRE keys dynamically. The local requesting GRE encapsulation without exchanging the GRE keys
mobility anchor MUST ignore the key in the GRE Key Identifier as it dynamically. If the Proxy Binding Update processing is successful,
is not used. If the Proxy Binding Update processing is successful,
the LMA sends a successful Proxy Binding Acknowledgement message with the LMA sends a successful Proxy Binding Acknowledgement message with
the GRE Key option included. In this case, the local mobility anchor the GRE Key option but the GRE Key Identifier field is omitted.
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.
When the mobile access gateway and the local mobility anchor When the mobile access gateway and the local mobility anchor
successfully negotiate the GRE encapsulation mode only, the mechanism successfully negotiate the GRE encapsulation mode only, then no GRE
of making the GRE keys, if being used, available to the MAG and LMA keys are used.
is out-of scope of this specification.
3.3. GRE Encapsulation and Keys Exchange 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 negotiate GRE encapsulation and exchange the local mobility anchor negotiate GRE encapsulation and exchange
downlink and uplink GRE keys using proxy mobile IPv6 registration downlink and uplink GRE keys using proxy mobile IPv6 registration
procedure. procedure.
3.3.1. Initial GRE Key Exchange 3.3.1. Initial GRE Key Exchange
skipping to change at page 8, line 40 skipping to change at page 8, line 33
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 specification. 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 for the
saved in the respected Binding Cache Entry (BCE) in the GRE key same mobility session in the GRE key option in a successful Proxy
option in a successful Proxy Binding Acknowledgement message sent to Binding Acknowledgement message sent to the new MAG.
the new MAG.
If the LMA receives a 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 makes a policy that is using GRE keys and GRE encapsulation, the LMA makes a policy
check regarding GRE encapsulation and GRE keys exchange. If, check regarding GRE encapsulation and GRE keys exchange. If,
according to the policy check, GRE encapsulation and GRE Keys according to the policy check, GRE encapsulation and GRE Keys
exchange are required, the LMA MUST reject the Proxy Binding Update exchange are required, the LMA MUST reject the Proxy Binding Update
by sending a Proxy Binding Acknowledgement message with the status by sending a Proxy Binding Acknowledgement message with the status
field is set to <GRE KEY OPTION REQUIRED> as defined in Section 6.4. field is set to <GRE KEY OPTION REQUIRED> as defined in Section 6.4.
Otherwise, the LMA SHOULD accept the Proxy Binding Update and if it Otherwise, the LMA SHOULD accept the Proxy Binding Update and if it
is processed successfully, the LMA MUST return a successful PBA is processed successfully, the LMA MUST return a successful Proxy
without including the GRE Key option. Binding Acknowledgement without including the GRE Key option.
4. Mobile Access Gateway Considerations 4. Mobile Access Gateway Considerations
4.1. Extensions to the Conceptual Data Structure 4.1. Extensions to the Conceptual Data Structure
Every mobile access gateway maintains a Binding Update List (BUL) Every mobile access gateway maintains a Binding Update List (BUL)
entry for each currently attached mobile node, as explained in entry for each currently attached mobile node, as explained in
Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213]. To Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213]. To
support this specification, the conceptual Binding Update List entry support this specification, the conceptual Binding Update List entry
data structure must be extended with the following three new data structure must be extended with the following three new
skipping to change at page 9, line 40 skipping to change at page 9, line 36
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
specification. specification.
4.2. Operational Summary 4.2. Operational Summary
o If the MAG determines that GRE encapsulation mode only 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 required, the MAG MUST include the GRE Key option but omit the GRE
Used (K) bit set in the Proxy Binding Update message that is sent Key Identifier field in the Proxy Binding Update message that is
to the local mobility anchor. The MAG MAY set the GRE Key sent to the local mobility anchor.
Identifier to any value as it is not being used.
o If the MAG determines that GRE encapsulation and GRE keys are 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 to the local mobility anchor. Binding Update message that is sent 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 with the Key NOT Used (K) bit set, the with the GRE Key option with the GRE Key Identifier field omitted,
mobile access gateway MUST update the mobile node Binding Update the mobile access gateway MUST update the mobile node Binding
List entry described in Section 4.1 by only setting the GRE Update List entry described in Section 4.1 by only setting the GRE
encapsulation enabled flag. encapsulation enabled flag.
o After receiving a successful Proxy Binding Acknowledgment message o After receiving a successful Proxy Binding Acknowledgment message
with the GRE Key option with the Key NOT Used (K) bit cleared and with the GRE Key option and the uplink GRE key included in the GRE
the uplink GRE key included, the mobile access gateway MUST update Key Identifier field, the mobile access gateway MUST update the
the related three fields in the mobile node Binding Update List related three fields in the mobile node Binding Update List entry
entry described in Section 4.1. Additionally, the MAG MUST use described in Section 4.1. Additionally, the MAG MUST use the
the assigned uplink GRE Key for tunneling all the traffic that assigned uplink GRE Key for tunneling all the traffic that belong
belong to this mobile node BUL entry and is originated from the to this mobile node BUL entry and is originated from the mobile
mobile node before forwarding the tunneled traffic to the LMA. node before forwarding the tunneled traffic to the LMA.
o If the mobile access gateway includes the GRE Key option in the o If the mobile access gateway includes the GRE Key option in the
Proxy Binding Update for a specific mobile node and the local Proxy Binding Update for a specific mobile node and the local
mobility anchor accepts the Proxy Binding Update by sending a mobility anchor accepts the Proxy Binding Update by sending a
Proxy Binding Acknowledgement with a success status code (less Proxy Binding Acknowledgement with a success status code (less
than 128) other than <GRE KEY OPTION NOT REQUIRED>, but without than 128) other than <GRE KEY OPTION NOT REQUIRED>, but without
the 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
skipping to change at page 11, line 24 skipping to change at page 11, line 19
removed before further processing takes place. removed before further processing takes place.
5. Local Mobility Anchor Considerations 5. Local Mobility Anchor Considerations
5.1. Extensions to the Binding Cache Entry 5.1. Extensions to the Binding Cache Entry
When the local mobility anchor and the mobile access gateway When the local mobility anchor and the mobile access gateway
successfully negotiate GRE encapsulation and exchange downlink and successfully negotiate GRE encapsulation and exchange downlink and
uplink GRE keys, the local mobility anchor MUST maintain the downlink uplink GRE keys, the local mobility anchor MUST maintain the downlink
and uplink GRE keys as part of the mobile node 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
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 If local mobility anchor successfully processes a Proxy Binding o If local mobility anchor successfully processes a Proxy Binding
Update message with the GRE Key option with the Key NOT Used (K) Update message with the GRE Key option but the GRE Key Identifier
bit set for Initial GRE Key exchange, the local mobility anchor field is omitted for Initial GRE Key exchange, the local mobility
MUST include the GRE Key option with the Key NOT Used (K) bit set anchor MUST include the GRE Key option but omit the GRE Key
when responding with a successful Proxy Binding Acknowledgement Identifier field when responding with a successful Proxy Binding
message. The LMA MAY set the GRE Key Identifier field in the GRE Acknowledgement message.
key option to any value including zero.
o If the local mobility anchor successfully processes a Proxy o If the local mobility anchor successfully processes a Proxy
Binding Update message with the GRE Key option with the Key NOT Binding Update message with the GRE Key option and the downlink
Used (K) bit cleared and downlink GRE key included in the GRE Key GRE key included in the GRE Key Identifier field for Initial GRE
Identifier field for Initial GRE Key exchange as in Section 3.3.1, Key exchange as in Section 3.3.1, the local mobility anchor MUST
the local mobility anchor MUST include the GRE Key option with the include the GRE Key option with the uplink GRE key included in the
Key NOT Used (K) bit cleared and the uplink GRE key included in GRE Key Identifier field when responding with a successful Proxy
the GRE Key Identifier field when responding with a successful Binding Acknowledgement message.
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 mobility binding, the local local mobility anchor for a specific mobility binding, the local
mobility anchor MUST use the negotiated downlink GRE key in the mobility anchor MUST use the negotiated downlink GRE key in the
GRE header of every packet that is destined to the mobile node of GRE header of every packet that is destined to the mobile node of
this specific binding over the GRE tunnel to the mobile access this specific binding over the GRE tunnel to the mobile access
gateway. 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
skipping to change at page 12, line 36 skipping to change at page 12, line 27
policy or LMA-MAG peer agreement, the local mobility anchor MUST policy or LMA-MAG peer agreement, the local mobility anchor MUST
reject the request and send a Proxy Binding Acknowledgement reject the request and send a Proxy Binding Acknowledgement
message to the mobile access gateway with the status code <GRE KEY message to the mobile access gateway with the status code <GRE KEY
OPTION REQUIRED> as defined in Section 6.4, indicating that GRE OPTION REQUIRED> as defined in Section 6.4, indicating that GRE
encapsulation and GRE keys are required. encapsulation and GRE keys are required.
o If after receiving and successfully processing a Proxy Binding o If after receiving and successfully processing a Proxy Binding
Update message with the GRE Key option, the local mobility anchor Update message with the GRE Key option, the local mobility anchor
determines based on a policy check that GRE encapsulation and GRE determines based on a policy check that GRE encapsulation and GRE
keys are 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 successful IPv4 addressing is not in use, the LMA SHOULD send a successful
Proxy Binding Acknowledgement message to the MAG with the status Proxy Binding Acknowledgement message to the MAG with the status
code <GRE KEY OPTION NOT REQUIRED>. The local mobility anchor code <GRE KEY OPTION NOT REQUIRED>. In this case, the local
MUST NOT include the GRE Key option in this Proxy Binding mobility anchor MUST NOT include the GRE Key option in the Proxy
Acknowledgement. Binding Acknowledgement.
o If the local mobility anchor successfully processes a de- o If the local mobility anchor successfully processes a de-
registration Proxy Binding Update message, the LMA follows the registration Proxy Binding Update message, the LMA follows the
same de-registration process as described in Proxy Mobile IPv6 same de-registration process as described in 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 header, the o On receiving a packet from the tunnel with the GRE header, the
local mobility anchor MUST use the GRE Key in the GRE extension local mobility anchor MUST use the GRE Key in the GRE extension
header as an additional identifier to determine which mobility header as an additional identifier to determine which mobility
skipping to change at page 13, line 28 skipping to change at page 13, line 21
mode only or GRE encapsulation and exchanging the downlink and uplink mode only or GRE encapsulation and exchanging the downlink and uplink
GRE keys. These GRE keys can be used by the peers in all GRE GRE keys. These GRE keys can be used by the peers in all GRE
encapsulated payload packets for marking that specific mobile node's encapsulated payload packets for marking that specific mobile node's
data traffic. data traffic.
The alignment requirement for this option is 4n. The alignment requirement for this option is 4n.
0 1 2 3 0 1 2 3
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 |K| Reserved | | Type | Length | 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. The Length field is option, excluding the type and length fields. If the Length field
always set to 6. is set to 2, it indicates that the GRE key Identifier field is not
being carried in the option. If the length field is set to a
Key NOT Used (K) value of 6, it means that either the downlink or the uplink GRE
key is carried.
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 contains the downlink or uplink GRE key. The value 32-bit field containing the downlink or the uplink GRE key. This
in this field is ignored when the Key NOT Used (K) bit set. field is present in the GRE Key option only if the GRE keys are
being exchanged using the Proxy Binding Update and Proxy Binding
Acknowledgement messages.
6.2. Proxy Binding Update Message Extension 6.2. Proxy Binding Update Message Extension
This specification extends the Proxy Binding Update message with one This specification extends the Proxy Binding Update message with one
new flag. The flag is shown and described below. new flag. The flag is shown and described below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | | Sequence # |
skipping to change at page 15, line 43 skipping to change at page 15, line 32
processed successfully but GRE Encapsulation and GRE Key is not processed successfully but GRE Encapsulation and GRE Key is not
required. 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 based on a policy check the local without the GRE Key option while based on a policy check the local
mobility anchor determines that GRE encapsulation is required for mobility anchor determines that GRE encapsulation is required for
this specific mobility session, the local mobility anchor uses this specific mobility session, the local mobility anchor uses
this code to reject the Proxy Binding Update and indicate to the this code to reject the Proxy Binding Update and indicate to the
mobile access gateway that GRE Encapsulation and Keys are mobile access gateway that GRE Encapsulation and GRE Keys are
required. required.
GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED (TBD less than 128) GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED (TBD less than 128)
If local mobility anchor receives a Proxy Binding Update with the If local mobility anchor receives a Proxy Binding Update with the
GRE Key option and TLV-header Format (T) flag set, the local GRE Key option and TLV-header Format (T) flag set, the local
mobility anchor uses this code to indicate to the mobile access mobility anchor uses this code to indicate to the mobile access
gateway that GRE Encapsulation has successfully been negotiated gateway that GRE Encapsulation has successfully been negotiated
BUT TLV-header format is NOT supported. but TLV-header format is NOT supported.
7. Data Packets Processing Considerations 7. Data Packets Processing Considerations
This section describes how the local mobility anchor and mobile This section describes how the local mobility anchor and mobile
access gateway encapsulate and decapsulate data packets when GRE access gateway encapsulate and decapsulate data packets when GRE
encapsulation and GRE Keys are used for tunneling mobile nodes data encapsulation and GRE Keys are used for tunneling mobile nodes data
traffic between these two mobility nodes. traffic between these two mobility nodes.
7.1. Tunneling Format 7.1. Tunneling Format
When GRE encapsulation and GRE keys have been negotiated between the When GRE encapsulation mode only or GRE encapsulation and GRE keys
mobile access gateway and the local mobility anchor for a specific have been negotiated between the mobile access gateway and the local
mobility session, the mobile access gateway is allowed to use various mobility anchor for a specific mobility session, the mobile access
tunneling formats depending on the mobile access gateway location and gateway is allowed to use various tunneling formats depending on the
the networks's capabilities between the MAG and the LMA. While using mobile access gateway location and the networks's capabilities
GRE encapsulation, the mobile access gateway can tunnel IPv6-or-IPv4 between the MAG and the LMA. While using GRE encapsulation, the
in IPv6 and IPv6-or-IPv4 in IPv4 using vanilla GRE tunneling based on mobile access gateway can tunnel IPv6-or-IPv4 in IPv6 and IPv6-or-
what described in [RFC5213] and [ID-PMIP6-IPv4], or use UDP IPv4 in IPv4 using vanilla GRE tunneling based on what described in
encapsulation to tunnel IPv6-or-IPv4 in IPv4. [RFC5213] and [ID-PMIP6-IPv4], or use UDP-based encapsulation to
tunnel IPv6-or-IPv4 in IPv4.
If UDP-based tunnelling is used between the mobile access gateway and If UDP-based tunneling is used between the mobile access gateway and
the local mobility anchor after NAT has been detected in the path the local mobility anchor after NAT has been detected in the path
between the MAG and the LMA while GRE encapsulation is required, the 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 TLV-header UDP tunneling format as shown in Figure 5 and described in
this specification MUST be used. this specification MUST be used.
[IPv4 Header] [IPv4 Header]
[UDP Header] [UDP Header]
[TLV Header] [TLV Header]
skipping to change at page 17, line 13 skipping to change at page 17, line 5
negotiated during the Proxy Binding Update/Acknowledgement exchange negotiated during the Proxy Binding Update/Acknowledgement exchange
as described in Section 7.3 and Section 7.4. If the TLV-header as described in Section 7.3 and Section 7.4. If the TLV-header
format is agreed upon between the mobile access gateway and local format is agreed upon between the mobile access gateway and local
mobility anchor, the LMA expects the TLV-header to follow the UDP 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 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- 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 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 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, 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 the TLV-header can carry traffic other than IP. The distinction
between IP and TLV encapsulation is needed because the Proxy Binding between IP and TLV encapsulation is needed, because the Proxy Binding
Update will never be sent in TLV-header UDP tunnel format. Update (IP Packet) and the data packets (GRE packets) can be sent
over the same UDP tunnel.
7.2. TLV-header Tunneling Negotiation 7.2. TLV-header Tunneling Negotiation
The mobile access gateway negotiates the format for tunnelling The mobile access gateway negotiates the format for tunneling payload
payload traffic during Proxy Mobile IPv6 registration procedure. If traffic during Proxy Mobile IPv6 registration procedure. If the
the mobile access gateway is required to use the TLV-header UDP mobile access gateway is required to use the TLV-header UDP
encapsulation format, the mobile access gateway MUST set the TLV- encapsulation format, the mobile access gateway MUST set the TLV-
header Format (T) flag in the Proxy Binding Update message sent to header Format (T) flag in the Proxy Binding Update message sent to
the local mobility anchor. If the local mobility anchor supports the the local mobility anchor. If the local mobility anchor supports the
TLV-header UDP tunneling format, the LMA SHOULD set the TLV-header TLV-header UDP tunneling format, the LMA SHOULD set the TLV-header
Format (T) flag in the Proxy Binding Acknowledgement. Otherwise, the Format (T) flag in the Proxy Binding Acknowledgement. Otherwise, the
TLV-header Format (T) flag is cleared. The setting of the TLV-header TLV-header Format (T) flag is cleared. The setting of the TLV-header
Format (T) flag in the Proxy Binding Acknowledgement indicates to the Format (T) flag in the Proxy Binding Acknowledgement indicates to the
mobile access gateway that it MUST use the TLV-header UDP mobile access gateway that it MUST use the TLV-header UDP
encapsulation format for all packets tunneled to the LMA for the encapsulation format for all packets tunneled to the LMA for the
entire duration the mobile node is attached to the mobile access entire duration the mobile node is attached to the mobile access
gateway. The TLV-header UDP tunneling format SHOULD NOT change gateway. The TLV-header UDP tunneling format SHOULD NOT change
during a Binding Lifetime Extension Proxy Binding Update (re- during a Binding Lifetime Extension Proxy Binding Update (re-
registration) from the same mobile access gateway. registration) from the same mobile access gateway.
Any handoff-triggered Binding Lifetime Extension Proxy Binding Update Any Proxy Binding Update message triggered by a handoff (Section
message may renegotiate the tunnelling format. Therefore, in order 5.3.4 of [RFC5213]) may renegotiate the tunneling format. Therefore,
to avoid interoperability issues, the local mobility anchor MUST NOT in order to avoid interoperability issues, the local mobility anchor
set the TLV-header Format (T) flag unless it was set in the Proxy MUST NOT set the TLV-header Format (T) flag unless it was set in the
Binding Update received from the mobile access gateway. Proxy Binding Update received from the mobile access gateway.
The TLV-header format is as shown below in Figure 6. The TLV-header format is as shown below in Figure 6.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TLV-header Format
Figure 6: TLV-header Format
Type Type
4-bit unsigned integer indicates the type of the payload following 4-bit unsigned integer indicates the type of the payload following
this header. The following are the only defined values as per this header. The following are the only defined values as per
this specification. this specification.
0 Reserved 0 Reserved
1 Generic Routing Encapsulation (GRE) [RFC2784] 1 Generic Routing Encapsulation (GRE) [RFC2784]
Length Length
skipping to change at page 18, line 34 skipping to change at page 18, line 32
7.3. Mobile Access Gateway Operation 7.3. Mobile Access Gateway Operation
When sending an IPv6 packet containing a Proxy Binding Update while When sending an IPv6 packet containing a Proxy Binding Update while
the network between the mobile access gateway and local mobility the network between the mobile access gateway and local mobility
anchor is an IPv4-only network, the mobile access gateway follows the anchor is an IPv4-only network, the mobile access gateway follows the
procedures specified in [ID-PMIP6-IPv4] and [ID-DSMIP6] if vanilla procedures specified in [ID-PMIP6-IPv4] and [ID-DSMIP6] if vanilla
UDP encapsulation format is used. However, if GRE encapsulation is UDP encapsulation format is used. However, if GRE encapsulation is
required and UDP based encapsulation is used, the mobile access required and UDP based encapsulation is used, the mobile access
gateway MUST set the TLV-header Format (T) flag in the Proxy Binding gateway MUST set the TLV-header Format (T) flag in the Proxy Binding
Update and follow this specification for GRE encapsulation and GRE Update and follow this specification for GRE encapsulation
keys exchange negotiation. If the received Proxy Binding negotiation. If the received Proxy Binding Acknowledgement is
Acknowledgement has the TLV-header Format (T) flag set, the MAG MUST successful and the TLV-header Format (T) flag set and the GRE Key
use the TLV-header UDP based encapsulation format as shown in option included, the MAG MUST use the TLV-header UDP based
Figure 5. encapsulation format as shown in Figure 5.
If the mobile access gateway sent a Proxy Binding Update with the GRE 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 key option included and the TLV-header Format (T) flag set and
received a successful Proxy Binding Acknowledgement with the GRE key received a successful Proxy Binding Acknowledgement with the GRE key
option included, the TLV-header Format (T) flag cleared, and the option included, the TLV-header Format (T) flag cleared, and the
status code <GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED>, the mobile status code <GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED>, the mobile
access gateway MUST NOT use GRE encapsulation for this mobility access gateway MUST NOT use GRE encapsulation for this mobility
session with UDP based tunneling. The mobile access gateway may session with UDP-based tunneling. The mobile access gateway may
resend the Proxy Binding Update to negotiate different tunneling resend the Proxy Binding Update to negotiate different tunneling
options, e.g., using UDP based tunneling without GRE encapsulation if options, e.g., using UDP based tunneling without GRE encapsulation if
possible or to de-register the the mobile node mobility session. possible or de-register the the mobile node mobility session.
7.3.1. Sending and Receiving Data Packets 7.3.1. Sending and Receiving Data Packets
When the mobile access gateway is located in an IPv6-enabled network, When the mobile access gateway is located in an IPv6-enabled network,
the mobile access gateway encapsulates and decapsulates IPv6 packets the mobile access gateway encapsulates and decapsulates IPv6 packets
as described in [RFC5213]. In this case, IPv4 payload traffic is as described in [RFC5213]. In this case, IPv4 payload traffic is
encapsulated in IPv6 packets before being sent to the local mobility encapsulated in IPv6 packets before being sent to the local mobility
anchor as described in [ID-PMIP6-IPv4]. In addition, if the mobile anchor as described in [ID-PMIP6-IPv4]. In addition, if the mobile
access gateway is located in an IPv4-only network and no UDP access gateway is located in an IPv4-only network and no UDP
tunneling format is used, the mobile access gateway encapsulates and tunneling format is used, the mobile access gateway encapsulates and
decapsulates IPv4 packets as described in [ID-PMIP6-IPv4]. IPv6 decapsulates IPv4 packets as described in [ID-PMIP6-IPv4]. IPv6
traffic is encapsulated in IPv4 packets following the procedure in traffic is encapsulated in IPv4 packets following the procedure in
[ID-PMIP6-IPv4] before being sent to the local mobility anchor. [ID-PMIP6-IPv4] before being sent to the local mobility anchor.
If the mobile access gateway have successfully negotiated GRE If the mobile access gateway have successfully negotiated GRE
encapsulation and GRE Keys as described in this specification for any encapsulation mode only or GRE encapsulation and GRE Keys as
of the above cases, the mobile access gateway encapsulates or described in this specification for any of the above cases, the
decapsulates data packets following the same procedure while ensuring mobile access gateway encapsulates or decapsulates data packets
that the GRE header is present as shown in Figure 7. following the same procedure while ensuring that the GRE header is
present as shown in Figure 7.
[IPv6-or-IPv4 Header] [IPv6-or-IPv4 Header]
[GRE Header] [GRE Header]
[payload - IPv6-or-IPv4 Header] [payload - IPv6-or-IPv4 Header]
Upper Layer protocols Upper Layer protocols
Figure 7: IPv6-or-IPv4 over IPv4 Using Vanilla GRE Encapsulation Figure 7: IPv6-or-IPv4 over IPv4 Using Vanilla GRE Encapsulation
skipping to change at page 20, line 24 skipping to change at page 20, line 24
Upper Layer protocols Upper Layer protocols
Figure 8: IPv6-or-IPv4 over IPv4 Using TLV-header UDP Tunneling Figure 8: IPv6-or-IPv4 over IPv4 Using TLV-header UDP Tunneling
7.4. Local Mobility Anchor Operation 7.4. Local Mobility Anchor Operation
When the local mobility anchor receives a Proxy Binding Update When the local mobility anchor receives a Proxy Binding Update
encapsulated in UDP and containing the IPv4 home address option, it encapsulated in UDP and containing the IPv4 home address option, it
needs to follow all the steps in [RFC5213] and [ID-PMIP6-IPv4]. In 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 addition, if the TLV-header Format (T) flag is set in the Proxy
Binding Update, the local mobility anchor needs to determine whether Binding Update, the local mobility anchor needs to determine whether
it can accept the TLV-header UDP based encapsulation format. If it 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 does, it SHOULD set the TLV-header Format (T) flag in the Proxy
Binding Acknowledgement. Otherwise, the LMA MUST NOT set the TLV- Binding Acknowledgement. Otherwise, the LMA MUST NOT set the TLV-
header Format (T) flag in the Proxy Binding Acknowledgement. header Format (T) flag in the Proxy Binding Acknowledgement.
If the local mobility anchor receives a Proxy Binding Update with the 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 GRE Key option and TLV-header Format (T) flag set and based on a
policy check, the local mobility anchor determines that GRE policy check, the local mobility anchor determines that GRE
encapsulation is required BUT the LMA does NOT support TLV-header encapsulation is required BUT the LMA does NOT support TLV-header
tunneling and if PBU has been successfully processed, the LMA MUST tunneling and if Proxy Binding Update has been successfully
send a successful Proxy Binding Acknowledgement with the status code processed, the LMA MUST send a successful Proxy Binding
<GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED>. This way, the local Acknowledgement with the status code <GRE TUNNELING BUT TLV-HEADER
mobility anchor indicates to the mobile access gateway that GRE NOT SUPPORTED>. This way, the local mobility anchor indicates to the
encapsulation and GRE keys have been successfully negotiated BUT GRE mobile access gateway that GRE encapsulation has been successfully
encapsulation MUST NOT be used while TLV-header UDP based tunneling negotiated BUT TLV-header UDP based tunneling format is not
format is not supported. supported.
If the local mobility anchor and the mobile access gateway have If the local mobility anchor and the mobile access gateway have
successfully negotiated the TLV-header UDP based tunneling format and successfully negotiated the TLV-header UDP based tunneling format and
the GRE encapsulation for a specific mobility session, the local the GRE encapsulation for a specific mobility session, the local
mobility anchor processes data packets as described in the following mobility anchor processes data packets as described in the following
subsection. subsection.
7.4.1. Sending and Receiving Data Packets 7.4.1. Sending and Receiving Data Packets
The local mobility anchor follows the rules specified in [RFC5213] The local mobility anchor follows the rules specified in [RFC5213]
for sending IPv6 payload packets to mobile nodes located in IPv6 for sending IPv6 payload packets to mobile nodes located in IPv6
through the mobile access gateway. When sending IPv4 packets to network through the mobile access gateway. When sending IPv4
mobile nodes in an IPv6 network, the local mobility anchor packets, destined to a mobile node, to the mobile access gateway that
encapsulates the IPv4 packets in IPv6 following the rules as is in an IPv6 network, the local mobility anchor encapsulates the
described in [ID-PMIP6-IPv4]. IPv4 packets in IPv6 following the rules as described in
[ID-PMIP6-IPv4]. Similarly, when sending IPv6 packets, destined to a
When sending IPv6 packets to a mobile node located in an IPv4 mobile node, to the mobile access gateway that is located in an IPv4
network, the local mobility anchor follows the format negotiated in network, the local mobility anchor follows the format negotiated in
the Proxy Binding Update/Acknowledgement exchange as described in the Proxy Binding Update/Acknowledgement exchange as described in
[ID-PMIP6-IPv4]. In the case when TLV-tunneling format and the GRE [ID-PMIP6-IPv4].
encapsulation for a specific mobility session have been successfully
negotiated between the local mobility anchor and the mobile access In the case when TLV-tunneling format and the GRE encapsulation for a
gateway, the local mobility anchor follows the TLV-header UDP based specific mobility session have been successfully negotiated between
headers tunneling order as shown in Figure 8 when sending or the local mobility anchor and the mobile access gateway, the local
receiving tunnelled IPv4 or IPv6 payload packets to or from the mobility anchor follows the TLV-header UDP based headers tunneling
mobile access gateway, respectively. order as shown in Figure 8 to encapsulate IPv4 or IPv6 payload
packets in IPv4 before sending the IPv4 packet to the mobile access
gateway. On the other hand, the local mobility anchor follows the
same TLV-header UDP based headers order when it decapsulates received
IPv4 packets from the mobile access gateway for the same mobility
session.
7.5. Mobile Node Operation 7.5. Mobile Node Operation
This specification has no impact on IPv4 or IPv6 mobile nodes. This specification has no impact on IPv4 or IPv6 mobile nodes.
8. IANA Considerations 8. IANA Considerations
This specification defines a new Mobility Option, the GRE Key Option, This specification defines a new Mobility Option, the GRE Key Option,
described in Section 6.1. This option is carried in the Mobility described in Section 6.1. This option is carried in the Mobility
Header. The type value for this option needs to be assigned from the Header. The type value for this option needs to be assigned from the
 End of changes. 44 change blocks. 
130 lines changed or deleted 127 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/