draft-ietf-netlmm-grekey-option-05.txt   draft-ietf-netlmm-grekey-option-06.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 22, 2009 S. Gundavelli Expires: August 28, 2009 S. Gundavelli
K. Leung K. Leung
Cisco Systems Cisco Systems
February 18, 2009 February 24, 2009
GRE Key Option for Proxy Mobile IPv6 GRE Key Option for Proxy Mobile IPv6
draft-ietf-netlmm-grekey-option-05.txt draft-ietf-netlmm-grekey-option-06.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 22, 2009. This Internet-Draft will expire on August 28, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Abstract Abstract
This specification defines a new Mobility Option for allowing the This specification defines a new Mobility Option for allowing the
mobile access gateway and the local mobility anchor to negotiate GRE mobile access gateway and the local mobility anchor to negotiate GRE
(Generic Routing Encapsulation) encapsulation mode and exchange the (Generic Routing Encapsulation) encapsulation mode and exchange the
downlink and uplink GRE keys which are used for marking the downlink downlink and uplink GRE keys which are used for marking the downlink
and uplink traffic that belong to a specific mobility session. In and uplink traffic that belong to a specific mobility session. In
addition, the same mobility option is used to explicitly negotiate addition, the same mobility option can be used to negotiate the GRE
the GRE encapsulation mode only without exchanging the GRE keys. encapsulation mode without exchanging the GRE keys.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . . . 5 3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . . . 5
3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 5 3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 5
3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 7 3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 7
skipping to change at page 2, line 38 skipping to change at page 2, line 38
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 . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . 15 7. Data Packets Processing Considerations . . . . . . . . . . . . 16
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 . . . . . . . . . . 20
7.5. Mobile Node Operation . . . . . . . . . . . . . . . . . . 21 7.5. Mobile Node Operation . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
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
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 binding. Thus, there is a need for an encapsulation mode specific mobility session. Thus, there is a need for an
with richer semantics. The Generic Routing Encapsulation (GRE) encapsulation mode with richer semantics. The Generic Routing
[RFC2784] and the Key extension as defined in [RFC2890], has the Encapsulation (GRE) [RFC2784] and the Key extension as defined in
required semantics to allow such distinction for use in Proxy Mobile [RFC2890], has the required semantics to allow such distinction for
IPv6. use in Proxy Mobile IPv6.
This specification defines the GRE Key option to be used for the This specification defines the GRE Key option to be used for the
negotiation of GRE encapsulation mode and exchange of the uplink and negotiation of GRE encapsulation mode and exchange of the uplink and
downlink GRE keys. The negotiated downlink and uplink GRE keys can downlink GRE keys. The negotiated downlink and uplink GRE keys can
be used for marking the downlink and uplink traffic for a specific be used for marking the downlink and uplink traffic for a specific
mobility session. In addition, this specification enables the mobile mobility session. In addition, this specification enables the mobile
access gateway and the local mobility anchor to explicitly negotiate access gateway and the local mobility anchor to negotiate the use of
the GRE encapsulation mode only using the GRE Key mobility option GRE encapsulation mode without exchanging the GRE keys.
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 31 skipping to change at page 5, line 31
The GRE key is assigned by the local mobility anchor and used by The GRE key is assigned by the local mobility anchor and used by
the mobile access gateway to mark the uplink traffic which belongs the mobile access gateway to mark the uplink traffic which belongs
to a specific mobility session as described in this specification. to a specific mobility session as described in this specification.
A Policy Check A Policy Check
When LMA receives an initial, handoff-triggered Binding Lifetime When LMA receives an initial, handoff-triggered Binding Lifetime
Extension, or Binding Lifetime Extension Proxy Binding Update for Extension, or Binding Lifetime Extension Proxy Binding Update for
a mobility session, the LMA determines if the GRE encapsulation a mobility session, the LMA determines if the GRE encapsulation
mode only or GRE encapsulation and GRE keys are required based on mode only or GRE encapsulation and GRE keys are required based on
a policy check. This policy could be a per MAG-LMA peer, a per- a policy check. This policy could be a per MAG-LMA pair, a per-
LMA local policy, a per-MN policy, or the combination of all. LMA local policy, a per-MN policy, or the combination of any of
them.
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
skipping to change at page 8, line 19 skipping to change at page 8, line 22
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 mobile node binding, the MAG MUST keys with the LMA for a specific mobile node binding, the MAG MUST
include the GRE Key option with the downlink GRE key in the Proxy include the GRE Key option with the downlink GRE key in the Proxy
Binding Update which is used for requesting a Binding Lifetime Binding Update which is used for requesting a Binding Lifetime
Extension. 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 keys exchange are
required, the new mobile access gateway MUST include the GRE key required, the new mobile access gateway MUST include the GRE key
option with the downlink GRE key in the Proxy Binding Update which is option with the downlink GRE key in the Proxy Binding Update which is
used for requesting an after handoff Binding Lifetime extension. In used for requesting an after handoff Binding Lifetime extension. In
this case, the new MAG may either pick a new downlink GRE key or use this case, the new MAG may either pick a new downlink GRE key or use
the downlink GRE key that was used by the previous MAG for the same the downlink GRE key that was used by the previous MAG for the same
binding. For the new MAG to know the downlink GRE key used by the binding. For the new MAG to know the downlink GRE key used by the
previous MAG, it may require transfer of context from the previous previous MAG, it may require transfer of context from the previous
MAG to the new MAG during a handoff. Such mechanisms are out-of- MAG to the new MAG during a handoff. Such mechanisms are out-of-
scope for this specification. scope for this specification.
skipping to change at page 10, line 39 skipping to change at page 10, line 39
mobile access gateway SHOULD resend the Proxy Binding Update mobile access gateway SHOULD resend the Proxy Binding Update
message with the GRE Key option. If the MAG does not support the message with the GRE Key option. If the MAG does not support the
GRE Key option, the MAG MAY log the event and possibly raise an GRE Key option, the MAG MAY log the event and possibly raise an
alarm to indicate a possible misconfiguration. alarm to indicate a possible misconfiguration.
o If the mobile access gateway sent a Proxy Binding Update message o If the mobile access gateway sent a Proxy Binding Update message
with the GRE Key option and the downlink GRE key included and with the GRE Key option and the downlink GRE key included and
received a successful Proxy Binding Acknowledgement message with a received a successful Proxy Binding Acknowledgement message with a
status code <GRE KEY OPTION NOT REQUIRED>, the mobile access status code <GRE KEY OPTION NOT REQUIRED>, the mobile access
gateway MUST consider that GRE encapsulation and GRE keys is not gateway MUST consider that GRE encapsulation and GRE keys is not
required for this specific mobility binding. The MAG follows required for this specific mobility session. The MAG follows
procedures in Proxy Mobile IPv6 specification [RFC5213] for the procedures in Proxy Mobile IPv6 specification [RFC5213] for the
handling of uplink and downlink traffic for this mobility binding handling of uplink and downlink traffic and MUST NOT include the
and MUST NOT include the GRE Key option in any subsequent Proxy GRE Key option in any subsequent Proxy Binding Update message that
Binding Update message that is sent to the LMA for this mobility is sent to the LMA for this mobility session.
session.
o If the MAG has successfully negotiated GRE encapsulation and o If the MAG has successfully negotiated GRE encapsulation and
exchanged the GRE keys with the LMA for a specific mobility exchanged the GRE keys with the LMA for a specific mobility
session, the MAG SHOULD NOT include the GRE Key option in the de- session, the MAG SHOULD NOT include the GRE Key option in the de-
registration Proxy Binding Update. registration Proxy Binding Update.
o On receiving a packet from the tunnel with the GRE header, the o On receiving a packet from the tunnel with the GRE header, the
mobile access gateway MUST use the GRE Key present in the GRE mobile access gateway MUST use the GRE Key present in the GRE
extension header as an additional identifier to determine which extension header as an additional identifier to determine which
mobility session this packet belongs to. The GRE header is mobility session this packet belongs to. The GRE header is
skipping to change at page 12, line 7 skipping to change at page 11, line 50
o If the local mobility anchor successfully processes a Proxy o If the local mobility anchor successfully processes a Proxy
Binding Update message with the GRE Key option and the downlink Binding Update message with the GRE Key option and the downlink
GRE key included in the GRE Key Identifier field for Initial GRE GRE key included in the GRE Key Identifier field for Initial GRE
Key exchange as in Section 3.3.1, the local mobility anchor MUST Key exchange as in Section 3.3.1, the local mobility anchor MUST
include the GRE Key option with the uplink GRE key included in the include the GRE Key option with the uplink GRE key included in the
GRE Key Identifier field when responding with a successful Proxy GRE Key Identifier field when responding with a successful Proxy
Binding Acknowledgement message. Binding Acknowledgement message.
o If the GRE tunneling is negotiated and the downlink and uplink GRE o If the GRE tunneling is negotiated and the downlink and uplink GRE
keys have been exchanged between the mobile access gateway and the keys have been exchanged between the mobile access gateway and the
local mobility anchor for a specific mobility binding, the local local mobility anchor for a specific mobility session, the local
mobility anchor MUST use the negotiated downlink GRE key in the mobility anchor MUST use the negotiated downlink GRE key in the
GRE header of every packet that is destined to the mobile node of GRE header of every packet that is destined to the mobile node of
this specific binding over the GRE tunnel to the mobile access this specific mobility session over the GRE tunnel to the mobile
gateway. access gateway.
o If the received Proxy Binding Update message does not contain the o If the received Proxy Binding Update message does not contain the
GRE Key option, and if the local mobility anchor based on a policy GRE Key option, and if the local mobility anchor based on a policy
check determines that GRE encapsulation and GRE keys are required, check determines that GRE encapsulation and GRE keys are required,
e.g., overlapping IPv4 private addressing is in use, LMA local e.g., overlapping IPv4 private addressing is in use, LMA local
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.
skipping to change at page 13, line 10 skipping to change at page 13, line 10
This section defines an extension to the Mobile IPv6 [RFC3775] This section defines an extension to the Mobile IPv6 [RFC3775]
protocol messages. The use of GRE Key option for supporting GRE protocol messages. The use of GRE Key option for supporting GRE
tunneling and GRE Key exchange for Proxy Mobile IPv6 is defined in tunneling and GRE Key exchange for Proxy Mobile IPv6 is defined in
this specification. this specification.
6.1. GRE Key Option 6.1. GRE Key Option
A new mobility option, the GRE Key option, is defined for use in the A new mobility option, the GRE Key option, is defined for use in the
Proxy Binding Update and Proxy Binding Acknowledgment messages Proxy Binding Update and Proxy Binding 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 also be used in Binding Update and Binding
mode only or GRE encapsulation and exchanging the downlink and uplink Acknowledgment messages exchanged between a mobile node and a home
GRE keys. These GRE keys can be used by the peers in all GRE agent.
encapsulated payload packets for marking that specific mobile node's
data traffic. This option can be used for negotiating GRE encapsulation 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 encapsulated
payload packets for marking that specific mobile node's data traffic.
The alignment requirement for this option is 4n. The alignment requirement for this option is 4n.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key Identifier | | GRE Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 26 skipping to change at page 14, line 32
|A|H|L|K|M|R|P|F|T| Reserved | Lifetime | |A|H|L|K|M|R|P|F|T| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Proxy Binding Update message Figure 3: Proxy Binding Update message
TLV-header Format (T) TLV-header Format (T)
When set, this flag indicates that the mobile access gateway When set, this flag indicates that the mobile access gateway
requests the use of the TLV-header for encapsulating IPv6-or-IPv4 requests the use of the TLV-header for encapsulating IPv6-or-IPv4
in IPv4. The TLV-header format is described later in this in IPv4. The TLV-header format is described later in this
specification. specification. None of the other fields or flags in the Proxy
Binding Update is modified by this specification.
6.3. Proxy Binding Acknowledgement Message Extension 6.3. Proxy Binding Acknowledgement Message Extension
This specification extends the Proxy Binding Acknowledgement message This specification extends the Proxy Binding Acknowledgement message
with a new flag. This new flag is shown and described below. with a new flag. This new 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|T| Res | | Status |K|R|P|T| Res |
skipping to change at page 15, line 4 skipping to change at page 15, line 14
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|T| Res | | Status |K|R|P|T| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime | | Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Proxy Binding Acknowledgement Message Figure 4: Proxy Binding Acknowledgement Message
TLV-header Format (T) TLV-header Format (T)
When set, this flag indicates that the sender of the Proxy Binding When set, this flag indicates that the sender of the Proxy Binding
Acknowledgement (LMA) supports tunneling IPv6-or-IPv4 in IPv4 Acknowledgement (LMA) supports tunneling IPv6-or-IPv4 in IPv4
using TLV-header format. using TLV-header format. None of the other fields or flags in the
Proxy Binding Acknowledgement is modified by this specification.
6.4. Status Codes 6.4. Status Codes
The following status code values are defined for use in the Binding The following status code values are defined for use in the Binding
Acknowledgment message when using Proxy Mobile IPv6. Acknowledgment message when using Proxy Mobile IPv6.
GRE KEY OPTION NOT REQUIRED (TBD less than 128) GRE KEY OPTION NOT REQUIRED (TBD less than 128)
When the local mobility anchor receives a Proxy Binding Update When the local mobility anchor receives a Proxy Binding Update
with the GRE Key option while based on a policy check the LMA with the GRE Key option while based on a policy check the LMA
determines that the GRE encapsulation is not required for this determines that the GRE encapsulation is not required for this
specific mobility session, the LMA uses this code to indicate to specific mobility session, the LMA uses this code to indicate to
the mobile access gateway that the Proxy Binding Update has been the mobile access gateway that the Proxy Binding Update has been
processed successfully but GRE Encapsulation and GRE Key is not processed successfully but GRE Encapsulation and GRE Keys are not
required. required.
GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED (TBD less than 128)
If local mobility anchor receives a Proxy Binding Update with the
GRE Key option and TLV-header Format (T) flag set, the local
mobility anchor uses this code to indicate to the mobile access
gateway that GRE Encapsulation has successfully been negotiated
but TLV-header format is NOT supported.
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 GRE 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)
If local mobility anchor receives a Proxy Binding Update with the
GRE Key option and TLV-header Format (T) flag set, the local
mobility anchor uses this code to indicate to the mobile access
gateway that GRE Encapsulation has successfully been negotiated
but TLV-header format is NOT supported.
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 mode only or GRE encapsulation and GRE keys When GRE encapsulation is used, the mobile access gateway is allowed
have been negotiated between the mobile access gateway and the local to use various tunneling formats depending on the mobile access
mobility anchor for a specific mobility session, the mobile access gateway location and the networks's capabilities between the MAG and
gateway is allowed to use various tunneling formats depending on the the LMA. Using vanilla GRE encapsulation, the mobile access gateway
mobile access gateway location and the networks's capabilities can tunnel IPv6-or-IPv4 payload packet in IPv6 or in IPv4 following
between the MAG and the LMA. While using GRE encapsulation, the the rules in [RFC5213] and [ID-PMIP6-IPv4].
mobile access gateway can tunnel IPv6-or-IPv4 in IPv6 and IPv6-or-
IPv4 in IPv4 using vanilla GRE tunneling based on what described in
[RFC5213] and [ID-PMIP6-IPv4], or use UDP-based encapsulation to
tunnel IPv6-or-IPv4 in IPv4.
If UDP-based tunneling 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 MUST be used.
this specification MUST be used.
[IPv4 Header] [IPv4 Header]
[UDP Header] [UDP Header]
[TLV Header] [TLV Header]
[GRE Header] [GRE Header]
[payload - IPv6-or-IPv4 Header] [payload - IPv6-or-IPv4 Header]
skipping to change at page 16, line 37 skipping to change at page 17, line 4
[TLV Header] [TLV Header]
[GRE Header] [GRE Header]
[payload - IPv6-or-IPv4 Header] [payload - IPv6-or-IPv4 Header]
Upper Layer protocols Upper Layer protocols
Figure 5: TLV-header UDP Based Encapsulation Headers Order Figure 5: TLV-header UDP Based Encapsulation Headers Order
When UDP based tunneling format is used between the mobile access When UDP based tunneling format is used between the mobile access
gateway and the local mobility anchor, the use of the TLV-header is gateway and the local mobility anchor, the use of the TLV-header is
negotiated during the Proxy Binding Update/Acknowledgement exchange negotiated during the Proxy Binding Update/Acknowledgement exchange
as described in Section 7.3 and Section 7.4. If the TLV-header as described in 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 field,
following payload packet and its length. The Type field in the TLV- the following payload packet header type and its length. The Type
header is limited to the values of 0 and 1 to ensure that the field in the TLV-header is always set to a value of 0 to enhance the
receiver can differentiate whether what after the UDP header is a processing of the received packet by ensuring that the receiver can
TLV-header Type field or an IP version field of an IP header. Hence, differentiate whether what after the UDP header is a TLV-header Type
the TLV-header can carry traffic other than IP. The distinction field or an IP version field of an IP header. Hence, the TLV-header
between IP and TLV encapsulation is needed, because the Proxy Binding can carry traffic other than IP as indicated in the Next Header
Update (IP Packet) and the data packets (GRE packets) can be sent field. The distinction between IP and TLV encapsulation is needed,
over the same UDP tunnel. because the Proxy Binding 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 tunneling payload The mobile access gateway negotiates the format for tunneling payload
traffic during Proxy Mobile IPv6 registration procedure. If the traffic during Proxy Mobile IPv6 registration procedure. If the
mobile access gateway is required to use the TLV-header UDP mobile access gateway is required to use the TLV-header UDP
encapsulation format, the mobile access gateway MUST set the TLV- encapsulation format, the mobile access gateway MUST set the TLV-
header Format (T) flag in the Proxy Binding Update message sent to header Format (T) flag in the Proxy Binding Update message sent to
the local mobility anchor. If the local mobility anchor supports the the local mobility anchor. If the local mobility anchor supports the
TLV-header UDP tunneling format, the LMA SHOULD set the TLV-header TLV-header UDP tunneling format, the LMA SHOULD set the TLV-header
skipping to change at page 17, line 39 skipping to change at page 18, line 8
5.3.4 of [RFC5213]) may renegotiate the tunneling format. Therefore, 5.3.4 of [RFC5213]) may renegotiate the tunneling format. Therefore,
in order to avoid interoperability issues, the local mobility anchor in order to avoid interoperability issues, the local mobility anchor
MUST NOT set the TLV-header Format (T) flag unless it was set in the MUST NOT set the TLV-header Format (T) flag unless it was set in the
Proxy Binding Update received from the mobile access gateway. Proxy Binding Update received from the mobile access gateway.
The TLV-header format is as shown below in Figure 6. The TLV-header format is as shown below in Figure 6.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Res. | Next Header | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TLV-header Format Figure 6: TLV-header Format
Type Type
4-bit unsigned integer indicates the type of the payload following This field is always 0 (zero) and distinguishes the TLV header
this header. The following are the only defined values as per from the IPv4 and IPv6 headers.
this specification.
0 Reserved Res.
1 Generic Routing Encapsulation (GRE) [RFC2784]
These fields are Reserved and unused. They MUST be initialized to
zero by the sender and MUST be ignored by the receiver.
Next Header
8-bit unsigned integer which indicates the protocol number of the
payload header following this TLV header. It is set to the
protocol number as assigned by IANA at the following
http://www.iana.org/assignments/protocol-numbers. e.g., if an IPv6
header follows, it should be '41'; '47' if it is a GRE header that
follows.
Length Length
16-bit unsigned integer indicating the length in octets of the 16-bit unsigned integer indicating the length in octets of the
payload following this header, excluding the TLV-header itself. payload following this header, excluding the TLV-header itself.
Reserved
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
7.3. Mobile Access Gateway Operation 7.3. Mobile Access Gateway Operation
When sending an IPv6 packet containing a Proxy Binding Update while When sending a Proxy Binding Update message while the network between
the network between the mobile access gateway and local mobility the mobile access gateway and local mobility anchor is an IPv4-only
anchor is an IPv4-only network, the mobile access gateway follows the network, the mobile access gateway follows the procedures specified
procedures specified in [ID-PMIP6-IPv4] and [ID-DSMIP6] if vanilla in [ID-PMIP6-IPv4] and [ID-DSMIP6] if vanilla UDP encapsulation
UDP encapsulation format is used. However, if GRE encapsulation is format is used. However, if GRE encapsulation is required and UDP
required and UDP based encapsulation is used, the mobile access based encapsulation is used, the mobile access gateway MUST set the
gateway MUST set the TLV-header Format (T) flag in the Proxy Binding TLV-header Format (T) flag in the Proxy Binding Update and follow
Update and follow this specification for GRE encapsulation this specification for GRE encapsulation negotiation. If the
negotiation. If the received Proxy Binding Acknowledgement is received Proxy Binding Acknowledgement is successful and the TLV-
successful and the TLV-header Format (T) flag set and the GRE Key header Format (T) flag set and the GRE Key option included, the MAG
option included, the MAG MUST use the TLV-header UDP based MUST use the TLV-header UDP based encapsulation format as shown in
encapsulation format as shown in Figure 5. Figure 5.
If the mobile access gateway sent a Proxy Binding Update with the GRE If the mobile access gateway receives a Proxy Binding Acknowledgement
key option included and the TLV-header Format (T) flag set and with the status <GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED> in
received a successful Proxy Binding Acknowledgement with the GRE key response to a Proxy Binding Update with the GRE key option and the
option included, the TLV-header Format (T) flag cleared, and the (T) flag set, the mobile access gateway MUST use GRE encapsulation
status code <GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED>, the mobile for this mobility session without UDP or TLV headers. A Proxy
access gateway MUST NOT use GRE encapsulation for this mobility Binding Acknowledgement message with status <GRE TUNNELING BUT TLV-
session with UDP-based tunneling. The mobile access gateway may HEADER NOT SUPPORTED> has the (T) flag cleared. The mobile access
resend the Proxy Binding Update to negotiate different tunneling gateway may resend the Proxy Binding Update to negotiate different
options, e.g., using UDP based tunneling without GRE encapsulation if tunneling options, e.g., using UDP based tunneling without GRE
possible or de-register the the mobile node mobility session. encapsulation if 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 or IPv4-
the mobile access gateway encapsulates and decapsulates IPv6 packets enabled network, it may be required to use vanilla GRE encapsulation
as described in [RFC5213]. In this case, IPv4 payload traffic is for tunneling IPv6 or IPv4 payload data packet to the local mobility
encapsulated in IPv6 packets before being sent to the local mobility anchor. In this case and if the mobile access gateway has
anchor as described in [ID-PMIP6-IPv4]. In addition, if the mobile successfully negotiated GRE encapsulation mode only or GRE
access gateway is located in an IPv4-only network and no UDP encapsulation and GRE Keys as described in this specification, the
tunneling format is used, the mobile access gateway encapsulates and mobile access gateway encapsulates or decapsulates IPv6-or-IPv4
decapsulates IPv4 packets as described in [ID-PMIP6-IPv4]. IPv6 payload packets following the rules described in [RFC5213] and
traffic is encapsulated in IPv4 packets following the procedure in [ID-PMIP6-IPv4] while ensuring that the GRE header is present as
[ID-PMIP6-IPv4] before being sent to the local mobility anchor. shown in Figure 7.
If the mobile access gateway have successfully negotiated GRE
encapsulation mode only or GRE encapsulation and GRE Keys as
described in this specification for any of the above cases, the
mobile access gateway encapsulates or decapsulates data packets
following the same procedure while ensuring that the GRE header is
present as shown in Figure 7.
[IPv6-or-IPv4 Header] [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
On the other hand, if the mobile access gateway is located in an On the other hand, if the mobile access gateway is located in an
IPv4-only network where NAT has been detected on the path between the IPv4-only network where NAT has been detected on the path between the
MAG and the LMA and successfully negotiated GRE encapsulation and the MAG and the LMA and successfully negotiated GRE encapsulation and the
TLV-header format, the mobile access gateway MUST use UDP TLV-header TLV-header format, the mobile access gateway MUST use UDP TLV-header
tunneling format when sending an IPv6 or IPv4 payload packet to the tunneling format when sending an IPv6 or IPv4 payload packet to the
LMA according to the format described in Figure 8. LMA according to the format described in Figure 5. The source and
the destination of the IPv4 outer header are V4CoA and HA_V4ADDR,
IPv4 header (src=V4CoA, dst=HA_V4ADDR) respectively. In addition the source and the destination IP
addresses of the IPv6-or-IPv4 payload data packet are V6/V4HoA and
[UDP Header] V6/V4CN, respectively.
[TLV Header]
[GRE Header]
IPv6/v4 header (src=V6/V4HoA, dst=V6/V4CN)
Upper Layer protocols
Figure 8: IPv6-or-IPv4 over IPv4 Using TLV-header UDP Tunneling
7.4. Local Mobility Anchor Operation 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 is 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
skipping to change at page 21, line 7 skipping to change at page 20, line 41
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 may use vanilla GRE encapsulation for
for sending IPv6 payload packets to mobile nodes located in IPv6 tunneling IPv6 or IPv4 payload data packet to the mobile access
network through the mobile access gateway. When sending IPv4 gateway. If the LMA has successfully negotiated GRE encapsulation
packets, destined to a mobile node, to the mobile access gateway that with the MAG for a specific mobility session, the local mobility
is in an IPv6 network, the local mobility anchor encapsulates the anchor encapsulates and decapsulates IPv6-or-IPv4 payload data
IPv4 packets in IPv6 following the rules as described in packets following the rules described in [RFC5213] and
[ID-PMIP6-IPv4]. Similarly, when sending IPv6 packets, destined to a [ID-PMIP6-IPv4] while ensuring that the GRE header is present as
mobile node, to the mobile access gateway that is located in an IPv4 shown in Figure 7.
network, the local mobility anchor follows the format negotiated in
the Proxy Binding Update/Acknowledgement exchange as described in
[ID-PMIP6-IPv4].
In the case when TLV-tunneling format and the GRE encapsulation for a In the case when TLV-tunneling format and the GRE encapsulation for a
specific mobility session have been successfully negotiated between specific mobility session have been successfully negotiated between
the local mobility anchor and the mobile access gateway, the local the local mobility anchor and the mobile access gateway, the local
mobility anchor follows the TLV-header UDP based headers tunneling mobility anchor follows the TLV-header UDP based tunneling format and
order as shown in Figure 8 to encapsulate IPv4 or IPv6 payload headers order as shown in Figure 5 to encapsulate IPv4 or IPv6
packets in IPv4 before sending the IPv4 packet to the mobile access payload packets in IPv4 before sending the IPv4 packet to the mobile
gateway. On the other hand, the local mobility anchor follows the access gateway. In this case, the source and the destination of the
same TLV-header UDP based headers order when it decapsulates received IPv4 outer header are HA_V4ADDR and V4CoA, respectively. In addition
IPv4 packets from the mobile access gateway for the same mobility the source and the destination IP addresses of the IPv6-or-IPv4
session. payload data packet are V6/V4CN and V6/V4HoA, respectively. On the
other hand, the local mobility anchor ensures the same TLV-header UDP
based tunneling format and 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. 38 change blocks. 
149 lines changed or deleted 140 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/