draft-ietf-netlmm-grekey-option-06.txt   draft-ietf-netlmm-grekey-option-07.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 28, 2009 S. Gundavelli Expires: October 28, 2009 S. Gundavelli
K. Leung K. Leung
Cisco Systems Cisco Systems
February 24, 2009 April 26, 2009
GRE Key Option for Proxy Mobile IPv6 GRE Key Option for Proxy Mobile IPv6
draft-ietf-netlmm-grekey-option-06.txt draft-ietf-netlmm-grekey-option-07.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 28, 2009. This Internet-Draft will expire on October 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect 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 can be used to negotiate the GRE addition, the same mobility option can be used to negotiate the GRE
encapsulation mode without exchanging the GRE keys. encapsulation mode without exchanging the GRE keys.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . . . 5 3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . . . 4
3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 5 3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 4
3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 7 3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 6
3.3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . 7 3.3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . 6
3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 7 3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 6
3.3.2. GRE Key Exchange During Binding Re-registration . . . 8 3.3.2. GRE Key Exchange During Binding Re-registration . . . 7
4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 9 4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 8
4.1. Extensions to the Conceptual Data Structure . . . . . . . 9 4.1. Extensions to the Conceptual Data Structure . . . . . . . 8
4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 9 4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 9
5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 11 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 10
5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 11 5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Proxy Binding Update Message Extension . . . . . . . . . . 14 6.2. Proxy Binding Update Message Extension . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . 20 7.4.1. Sending and Receiving Data Packets . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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 as specified in [RFC2473] and [RFC2003] for the
between the local mobility anchor and the mobile access gateway. tunneled traffic between the local mobility anchor and the mobile
There are scenarios where these encapsulation modes are not access gateway. There are scenarios where these encapsulation modes
sufficient to uniquely identify the destination of packets of a are not sufficient to uniquely identify the destination of packets of
specific mobility session. Thus, there is a need for an a specific mobility session. Thus, there is a need for an
encapsulation mode with richer semantics. The Generic Routing encapsulation mode with richer semantics. The Generic Routing
Encapsulation (GRE) [RFC2784] and the Key extension as defined in Encapsulation (GRE) [RFC2784] and the Key extension as defined in
[RFC2890], has the required semantics to allow such distinction for [RFC2890], has the required semantics to allow such distinction for
use in Proxy Mobile 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 negotiate the use of Access Gateway (MAG) and the Local Mobility Anchor (LMA) to negotiate
GRE encapsulation mode without exchanging the GRE keys. the use of GRE encapsulation mode without exchanging the GRE keys.
This specification has no impact on IPv4 or IPv6 mobile nodes.
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 27 skipping to change at page 4, line 27
specification. specification.
Uplink GRE Key Uplink GRE Key
The GRE key is assigned by the local mobility anchor and used by The GRE key is assigned by the local mobility anchor and used by
the mobile access gateway to mark the uplink traffic which belongs the mobile access gateway to mark the uplink traffic which belongs
to a specific mobility session 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 local mobility anchor receives an initial, handoff-triggered
Extension, or Binding Lifetime Extension Proxy Binding Update for Binding Lifetime Extension, or Binding Lifetime Extension Proxy
a mobility session, the LMA determines if the GRE encapsulation Binding Update for a mobility session, the local mobility anchor
mode only or GRE encapsulation and GRE keys are required based on determines if the GRE encapsulation mode only or GRE encapsulation
a policy check. This policy could be a per MAG-LMA pair, a per- and GRE keys are required based on a policy check. This policy
LMA local policy, a per-MN policy, or the combination of any of could be a per MAG-LMA pair, a per-LMA local policy, a per-MN
them. policy, or the combination of any of them.
3. GRE Encapsulation and Keys Exchange 3. GRE Encapsulation and Keys Exchange
This section describes how GRE encapsulation mode is negotiated and
the GRE keys are dynamically exchanged while using Proxy Mobile IPv6
protocol [RFC5213] signaling.
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 mobile
the LMA, then no GRE keys are used. access gateway and the local mobility anchor, then no GRE keys are
used.
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 28 skipping to change at page 6, line 33
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 but omit the GRE Key Identifier field MUST include the GRE Key option but omit the GRE Key Identifier field
in the Proxy Binding Update. in the Proxy Binding Update.
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 but the GRE received Proxy Binding Update contains the GRE Key option but the GRE
Key Identifier field is omitted, the mobile access gateway is Key Identifier field is omitted, the mobile access gateway is
requesting GRE encapsulation without exchanging the GRE keys requesting GRE encapsulation without exchanging the GRE keys
dynamically. If the Proxy Binding Update processing is successful, dynamically. If the Proxy Binding Update processing is successful,
the LMA sends a successful Proxy Binding Acknowledgement message with the local mobility anchor sends a successful Proxy Binding
the GRE Key option but the GRE Key Identifier field is omitted. Acknowledgement message with the GRE Key option but the GRE Key
Identifier field is omitted.
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, then no GRE successfully negotiate the GRE encapsulation mode only, then no GRE
keys are used. keys are used.
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
When the mobile access gateway determines, based on, e.g., private When the mobile access gateway determines, based on, e.g., private
IPv4 address support [RFC1918], the MAG local policy, or the MAG-LMA IPv4 address support [RFC1918], the mobile access gateway local
peer agreement, that GRE encapsulation is needed and GRE keys are policy, or the MAG-LMA peer agreement, that GRE encapsulation is
required, the mobile access gateway MUST include the GRE Key option needed and GRE keys are required, the mobile access gateway MUST
in the initial Proxy Binding Update message sent to the local include the GRE Key option in the initial Proxy Binding Update
mobility anchor. The mobile access gateway MUST include the downlink message sent to the local mobility anchor. The mobile access gateway
GRE key in the GRE Key Identifier field of the GRE Key option. MUST include the downlink GRE key in the GRE Key Identifier field of
the GRE Key option.
After the LMA successfully processes the initial Proxy Binding Update After the local mobility anchor successfully processes the initial
and accepts the GRE encapsulation request and the downlink GRE key Proxy Binding Update and accepts the GRE encapsulation request and
based on a policy check, the LMA MUST include the GRE Key option with the downlink GRE key based on a policy check, the local mobility
the uplink GRE key in the GRE Key Identifier field in a successful anchor MUST include the GRE Key option with the uplink GRE key in the
Proxy Binding Acknowledgement and send it to the MAG. GRE Key Identifier field in a successful Proxy Binding
Acknowledgement and send it to the mobile access gateway.
3.3.2. GRE Key Exchange During Binding Re-registration 3.3.2. GRE Key Exchange During Binding Re-registration
If the MAG has successfully negotiated and exchanged the initial GRE If the mobile access gateway has successfully negotiated and
keys with the LMA for a specific mobile node binding, the MAG MUST exchanged the initial GRE keys with the local mobility anchor for a
include the GRE Key option with the downlink GRE key in the Proxy specific mobile node binding, the mobile access gateway MUST include
Binding Update which is used for requesting a Binding Lifetime the GRE Key option with the downlink GRE key in the Proxy Binding
Extension. Update which is used for requesting a Binding Lifetime Extension. In
this case, if the local mobility anchor successfully processes the
Proxy Binding Update message, the local mobility anchor MUST return
the same uplink GRE key that was exchanged with the mobile access
gateway for the same mobility session in the GRE key option in a
successful Proxy Binding Acknowledgement message.
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 mobile access gateway local policy, the MAG-LMA peer agreement, or an
the handoff process, that GRE encapsulation and GRE keys exchange are indication during the handoff process, that GRE encapsulation and GRE
required, the new mobile access gateway MUST include the GRE key keys exchange are required, the new mobile access gateway MUST
option with the downlink GRE key in the Proxy Binding Update which is include the GRE key option with the downlink GRE key in the Proxy
used for requesting an after handoff Binding Lifetime extension. In Binding Update which is used for requesting an after handoff Binding
this case, the new MAG may either pick a new downlink GRE key or use Lifetime extension. In this case, the new mobile access gateway may
the downlink GRE key that was used by the previous MAG for the same either pick a new downlink GRE key or use the downlink GRE key that
binding. For the new MAG to know the downlink GRE key used by the was used by the previous mobile access gateway for the same binding.
previous MAG, it may require transfer of context from the previous For the new mobile access gateway to know the downlink GRE key used
MAG to the new MAG during a handoff. Such mechanisms are out-of- by the previous mobile access gateway, it may require transfer of
scope for this specification. context from the previous mobile access gateway to the new mobile
access gateway during a handoff. Such mechanisms are out-of-scope
for this specification.
If the LMA successfully processes a handoff-triggered Binding If the local mobility anchor successfully processes a handoff-
Lifetime Extension Proxy Binding Update message which contains a GRE triggered Binding Lifetime Extension Proxy Binding Update message
key option with a downlink GRE key included, the LMA MUST return the which contains a GRE key option with a downlink GRE key included, the
same uplink GRE key that was exchanged with the previous MAG for the local mobility anchor MUST return the same uplink GRE key that was
same mobility session in the GRE key option in a successful Proxy exchanged with the previous mobile access gateway for the same
Binding Acknowledgement message sent to the new MAG. mobility session in the GRE key option in a successful Proxy Binding
Acknowledgement.
If the LMA receives a handoff-triggered Binding Lifetime Extension If the local mobility anchor receives a handoff-triggered Binding
Proxy Binding Update message without the GRE key option for a BCE Lifetime Extension Proxy Binding Update message without the GRE key
that is using GRE keys and GRE encapsulation, the LMA makes a policy option for a Binding Cache Entry (BCE) that is using GRE keys and GRE
check regarding GRE encapsulation and GRE keys exchange. If, encapsulation, the local mobility anchor makes a policy check
according to the policy check, GRE encapsulation and GRE Keys regarding GRE encapsulation and GRE keys exchange. If, according to
exchange are required, the LMA MUST reject the Proxy Binding Update the policy check, GRE encapsulation and GRE Keys exchange are
by sending a Proxy Binding Acknowledgement message with the status required, the local mobility anchor MUST reject the Proxy Binding
field is set to <GRE KEY OPTION REQUIRED> as defined in Section 6.4. Update by sending a Proxy Binding Acknowledgement message with the
Otherwise, the LMA SHOULD accept the Proxy Binding Update and if it status field is set to <GRE KEY OPTION REQUIRED> as defined in
is processed successfully, the LMA MUST return a successful Proxy Section 6.4. Otherwise, the local mobility anchor SHOULD accept the
Binding Acknowledgement without including the GRE Key option. Proxy Binding Update and if it is processed successfully, the local
mobility anchor MUST return a successful Proxy 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
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. mobile node's traffic.
o The downlink GRE key used in the GRE encapsulation header of the o The downlink GRE key used in the GRE encapsulation header of the
tunneled payload packet from the local mobility anchor to the tunneled payload packet from the local mobility anchor to the
mobile access gateway that is destined to the mobile node. This mobile access gateway that is destined to the mobile node. This
GRE key is generated by the MAG and communicated to the LMA in the GRE key is generated by the mobile access gateway and communicated
GRE Key option in the Proxy Binding Update message. to the local mobility anchor in the GRE Key option in the Proxy
Binding Update message.
o The uplink GRE key used in the GRE encapsulation header of the o The uplink GRE key used in the GRE encapsulation header of the
tunneled payload packet from the mobile access gateway to the tunneled payload packet from the mobile access gateway to the
local mobility anchor that is originating from the mobile node. local mobility anchor that is originating from the mobile node.
This GRE key is obtained from the GRE Key Identifier field of the This GRE key is obtained from the GRE Key Identifier field of the
GRE Key option present in the received Proxy Binding GRE Key option present in the received Proxy Binding
Acknowledgement message sent by the LMA as specified in this Acknowledgement message sent by the local mobility anchor as
specification. specified in this specification.
4.2. Operational Summary o A flag indicating whether UDP based TLV-Header format Section 7.2
is enabled for the mobile node's traffic. This flag is TRUE only
when UDP tunneling as in [ID-PMIP6-IPv4] and GRE Encapsulation as
in this specification are both enabled for this mobility session.
o If the MAG determines that GRE encapsulation mode only is 4.2. Operational Summary
required, the MAG MUST include the GRE Key option but omit the GRE
Key Identifier field in the Proxy Binding Update message that is
sent to the local mobility anchor.
o If the MAG determines that GRE encapsulation and GRE keys are o If the mobile access gateway determines that GRE encapsulation
required, the MAG MUST include the GRE Key option with the mode only is required, the mobile access gateway MUST include the
downlink GRE key in the GRE Key Identifier field in the Proxy GRE Key option but omit 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 If the mobile access gateway determines that GRE encapsulation and
GRE keys are required, the mobile access gateway MUST include the
GRE Key option with the downlink GRE key in the GRE Key Identifier
field in the Proxy 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 GRE Key Identifier field omitted, with the GRE Key option with the GRE Key Identifier field omitted,
the mobile access gateway MUST update the mobile node Binding the mobile access gateway MUST update the mobile node Binding
Update 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 and the uplink GRE key included in the GRE with the GRE Key option and the uplink GRE key included in the GRE
Key Identifier field, the mobile access gateway MUST update the Key Identifier field, the mobile access gateway MUST update the
related three fields in the mobile node Binding Update List entry related three fields in the mobile node Binding Update List entry
described in Section 4.1. Additionally, the MAG MUST use the described in Section 4.1. Additionally, the mobile access gateway
assigned uplink GRE Key for tunneling all the traffic that belong MUST use the assigned uplink GRE Key for tunneling all the traffic
to this mobile node BUL entry and is originated from the mobile that belong to this mobile node BUL entry and is originated from
node before forwarding the tunneled traffic to the LMA. the mobile node before forwarding the tunneled traffic to the
local mobility anchor.
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
message that is sent to that LMA. message that is sent to that local mobility anchor.
o If the mobile access gateway sent a Proxy Binding Update message o If the mobile access gateway sent a Proxy Binding Update message
without the GRE Key option, but the received Proxy Binding without the GRE Key option, but the received Proxy Binding
Acknowledgement has the Status Code <GRE KEY OPTION REQUIRED>, Acknowledgement has the Status Code <GRE KEY OPTION REQUIRED>,
indicating that the GRE encapsulation and GRE key is required, the indicating that the GRE encapsulation and GRE key is required, the
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 mobile access gateway
GRE Key option, the MAG MAY log the event and possibly raise an does not support the GRE Key option, it MAY log the event and
alarm to indicate a possible misconfiguration. possibly raise an 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 session. The MAG follows required for this specific mobility session. The mobile access
procedures in Proxy Mobile IPv6 specification [RFC5213] for the gateway follows procedures in Proxy Mobile IPv6 specification
handling of uplink and downlink traffic and MUST NOT include the [RFC5213] for the handling of uplink and downlink traffic and MUST
GRE Key option in any subsequent Proxy Binding Update message that NOT include the GRE Key option in any subsequent Proxy Binding
is sent to the LMA for this mobility session. Update message that is sent to the local mobility anchor for this
mobility session.
o If the MAG has successfully negotiated GRE encapsulation and o If the mobile access gateway has successfully negotiated GRE
exchanged the GRE keys with the LMA for a specific mobility encapsulation and exchanged the GRE keys with the local mobility
session, the MAG SHOULD NOT include the GRE Key option in the de- anchor for a specific mobility session, the mobile access gateway
registration Proxy Binding Update. SHOULD NOT include the GRE Key option in the de-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
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's BCE. This requires
that the BCE described in section 5.1 of the Proxy Mobile IPv6 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 mobile access gateway and
encapsulation header of the tunneled payload packet from the local used in the GRE encapsulation header of the tunneled payload
mobility anchor to the mobile access gateway. packet from the local 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 local mobility anchor and used
encapsulation header of the tunneled payload packet from the in the GRE encapsulation header of the tunneled payload packet
mobile access gateway to the local mobility anchor. from the mobile access gateway to the local mobility anchor.
o A flag indicating whether UDP based TLV-Header format Section 7.2
is enabled for the mobile node's traffic. This flag is TRUE only
when UDP tunneling as in [ID-PMIP6-IPv4] and GRE Encapsulation as
in this specification are both enabled for this mobility session.
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 but the GRE Key Identifier Update message with the GRE Key option but the GRE Key Identifier
field is omitted for Initial GRE Key exchange, the local mobility field is omitted for Initial GRE Key exchange, the local mobility
anchor MUST include the GRE Key option but omit the GRE Key anchor MUST include the GRE Key option but omit the GRE Key
Identifier field when responding with a successful Proxy Binding Identifier field when responding with a successful Proxy Binding
Acknowledgement message. Acknowledgement message.
skipping to change at page 12, line 12 skipping to change at page 11, line 47
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 session, 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 mobility session over the GRE tunnel to the mobile this specific mobility session over the GRE tunnel to the mobile
access 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, local
policy or LMA-MAG peer agreement, the local mobility anchor MUST mobility anchor local policy or LMA-MAG peer agreement, the local
reject the request and send a Proxy Binding Acknowledgement mobility anchor MUST reject the request and send a Proxy Binding
message to the mobile access gateway with the status code <GRE KEY Acknowledgement message to the mobile access gateway with the
OPTION REQUIRED> as defined in Section 6.4, indicating that GRE status code <GRE KEY OPTION REQUIRED> as defined in Section 6.4,
encapsulation and GRE keys are required. indicating that GRE 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 SHOULD send a successful IPv4 addressing is not in use, the local mobility anchor SHOULD
Proxy Binding Acknowledgement message to the MAG with the status send a successful Proxy Binding Acknowledgement message to the
code <GRE KEY OPTION NOT REQUIRED>. In this case, the local mobile access gateway with the status code <GRE KEY OPTION NOT
mobility anchor MUST NOT include the GRE Key option in the Proxy REQUIRED>. In this case, the local mobility anchor MUST NOT
Binding Acknowledgement. include the GRE Key option in the Proxy Binding Acknowledgement.
o If the local mobility anchor successfully processes a de- o If the local mobility anchor successfully processes a de-
registration Proxy Binding Update message, the LMA follows the registration Proxy Binding Update message, the local mobility
same de-registration process as described in Proxy Mobile IPv6 anchor follows the same de-registration process as described in
specification [RFC5213] to clean the binding cache entry and all Proxy Mobile IPv6 specification [RFC5213] to clean the binding
associated resources including the downlink and uplink GRE keys. cache entry and all 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
session this packet belongs to. The GRE header is removed before session this packet belongs to. The GRE header is removed before
further processing takes place. further processing takes place.
6. Message Formats 6. Message Formats
This section defines an extension to the Mobile IPv6 [RFC3775] This section defines an extension to the Mobile IPv6 [RFC3775]
protocol messages. The use of GRE Key option for supporting GRE protocol messages. The use of GRE Key option for supporting GRE
tunneling and GRE Key exchange for Proxy Mobile IPv6 is defined in tunneling and GRE Key exchange for Proxy Mobile IPv6 is defined in
this 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 also be used in Binding Update and Binding anchor. This option can be used for negotiating GRE encapsulation
Acknowledgment messages exchanged between a mobile node and a home mode only or GRE encapsulation and exchanging the downlink and uplink
agent. GRE keys. These GRE keys can be used by the peers in all GRE
encapsulated payload packets for marking that specific mobile node's
This option can be used for negotiating GRE encapsulation mode only data traffic.
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 14 skipping to change at page 13, line 42
GRE Key Identifier GRE Key Identifier
32-bit field containing the downlink or the uplink GRE key. This 32-bit field containing the downlink or the uplink GRE key. This
field is present in the GRE Key option only if the GRE keys are field is present in the GRE Key option only if the GRE keys are
being exchanged using the Proxy Binding Update and Proxy Binding being exchanged using the Proxy Binding Update and Proxy Binding
Acknowledgement messages. Acknowledgement messages.
6.2. 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 as
new flag. The flag is shown and described below. defined in [RFC5213] with the new TLV-Header format (T) flag. The
new (T) flag is described below and shown as part of the Proxy
Binding Update message as in Figure 3.
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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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
skipping to change at page 14, line 38 skipping to change at page 14, line 26
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. None of the other fields or flags in the Proxy specification. None of the other fields or flags in the Proxy
Binding Update is modified by this specification. 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. as defined in [RFC5213] with the new TLV-Header format (T) flag. The
new (T) flag is described below and shown as part of the Proxy
Binding Acknowledgement message as in Figure 4.
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
skipping to change at page 15, line 30 skipping to change at page 15, line 14
Proxy Binding Acknowledgement is modified by this specification. 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 local
determines that the GRE encapsulation is not required for this mobility anchor determines that the GRE encapsulation is not
specific mobility session, the LMA uses this code to indicate to required for this specific mobility session, the local mobility
the mobile access gateway that the Proxy Binding Update has been anchor uses this code to indicate to the mobile access gateway
processed successfully but GRE Encapsulation and GRE Keys are not that the Proxy Binding Update has been processed successfully but
required. GRE Encapsulation and GRE Keys are not 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.
GRE KEY OPTION REQUIRED (TBD more than 128) GRE KEY OPTION REQUIRED (TBD more than 128)
skipping to change at page 16, line 26 skipping to change at page 16, line 4
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 is used, the mobile access gateway is allowed When GRE encapsulation is used, the mobile access gateway is allowed
to use various tunneling formats depending on the mobile access to use various tunneling formats depending on the mobile access
gateway location and the networks's capabilities between the MAG and gateway location and the networks's capabilities between the mobile
the LMA. Using vanilla GRE encapsulation, the mobile access gateway access gateway and the local mobility anchor. Using GRE
can tunnel IPv6-or-IPv4 payload packet in IPv6 or in IPv4 following encapsulation, as described in [RFC2784] and [RFC2890], the mobile
the rules in [RFC5213] and [ID-PMIP6-IPv4]. access gateway can tunnel IPv6-or-IPv4 payload packet in IPv6 or in
IPv4 following the rules in [RFC5213] and [ID-PMIP6-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 mobile access gateway and the local mobility anchor while
TLV-header UDP tunneling format as shown in Figure 5 MUST be used. GRE encapsulation is required, the TLV-header UDP tunneling format as
shown in Figure 5 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 17, line 4 skipping to change at page 16, line 29
[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 local mobility anchor expects the TLV-header to
header as shown in Figure 5. The TLV header contains the type field, follow the UDP header as shown in Figure 5. The TLV header contains
the following payload packet header type and its length. The Type the type field, the following payload packet header type and its
field in the TLV-header is always set to a value of 0 to enhance the length. The Type field in the TLV-header is always set to a value of
processing of the received packet by ensuring that the receiver can 0 to enhance the processing of the received packet by ensuring that
differentiate whether what after the UDP header is a TLV-header Type the receiver can differentiate whether what after the UDP header is a
field or an IP version field of an IP header. Hence, the TLV-header TLV-header Type field or an IP version field of an IP header. Hence,
can carry traffic other than IP as indicated in the Next Header the TLV-header can carry traffic other than IP as indicated in the
field. The distinction between IP and TLV encapsulation is needed, Next Header field. The distinction between IP and TLV encapsulation
because the Proxy Binding Update (IP Packet) and the data packets is needed, because the Proxy Binding Update (IP Packet) and the data
(GRE packets) can be sent over the same UDP tunnel. packets (GRE packets) can be sent over the same UDP tunnel.
When processing a UDP packet with the TLV-Header format, if the
receiving node found that the payload packet length as calculated
from the UDP header length field is different than its length as
calculated from the TLV-header length field, the receiving node MUST
discard the received IP packet.
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 local mobility anchor SHOULD set
Format (T) flag in the Proxy Binding Acknowledgement. Otherwise, the the TLV-header Format (T) flag in the Proxy Binding Acknowledgement.
TLV-header Format (T) flag is cleared. The setting of the TLV-header Otherwise, the TLV-header Format (T) flag is cleared. The setting of
Format (T) flag in the Proxy Binding Acknowledgement indicates to the the TLV-header Format (T) flag in the Proxy Binding Acknowledgement
mobile access gateway that it MUST use the TLV-header UDP indicates to the mobile access gateway that it MUST use the TLV-
encapsulation format for all packets tunneled to the LMA for the header UDP encapsulation format for all packets tunneled to the local
entire duration the mobile node is attached to the mobile access mobility anchor for the entire duration the mobile node is attached
gateway. The TLV-header UDP tunneling format SHOULD NOT change to the mobile access gateway. The TLV-header UDP tunneling format
during a Binding Lifetime Extension Proxy Binding Update (re- SHOULD NOT change during a Binding Lifetime Extension Proxy Binding
registration) from the same mobile access gateway. Update (re-registration) from the same mobile access gateway.
Any Proxy Binding Update message triggered by a handoff (Section Any Proxy Binding Update message triggered by a handoff (Section
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
skipping to change at page 18, line 42 skipping to change at page 18, line 33
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.
7.3. Mobile Access Gateway Operation 7.3. Mobile Access Gateway Operation
When sending a Proxy Binding Update message while the network between When sending a Proxy Binding Update message while the network between
the mobile access gateway and local mobility anchor is an IPv4-only the mobile access gateway and local mobility anchor is an IPv4-only
network, the mobile access gateway follows the procedures specified network, the mobile access gateway follows the procedures specified
in [ID-PMIP6-IPv4] and [ID-DSMIP6] if vanilla UDP encapsulation in [ID-PMIP6-IPv4] if regular UDP encapsulation format is used.
format is used. However, if GRE encapsulation is required and UDP However, if GRE encapsulation is required and UDP based encapsulation
based encapsulation is used, the mobile access gateway MUST set the is used, the mobile access gateway MUST set the TLV-header Format (T)
TLV-header Format (T) flag in the Proxy Binding Update and follow flag in the Proxy Binding Update and follow this specification for
this specification for GRE encapsulation negotiation. If the GRE encapsulation negotiation. If the received Proxy Binding
received Proxy Binding Acknowledgement is successful and the TLV- Acknowledgement is successful and the TLV-header Format (T) flag set
header Format (T) flag set and the GRE Key option included, the MAG and the GRE Key option included, the mobile access gateway MUST
MUST use the TLV-header UDP based encapsulation format as shown in update the mobile node Binding Update List entry described in
Figure 5. Section 4.1 by setting the UDP based TLV-Header format flag. In this
case, the mobile access gateway MUST use the TLV-header UDP based
encapsulation format as shown in Figure 5.
If the mobile access gateway receives a Proxy Binding Acknowledgement If the mobile access gateway receives a Proxy Binding Acknowledgement
with the status <GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED> in with the status <GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED> in
response to a Proxy Binding Update with the GRE key option and the response to a Proxy Binding Update with the GRE key option and the
(T) flag set, the mobile access gateway MUST use GRE encapsulation (T) flag set, the mobile access gateway MUST use GRE encapsulation
for this mobility session without UDP or TLV headers. A Proxy without UDP encapsulation. If the mobile access gateway is allowed
Binding Acknowledgement message with status <GRE TUNNELING BUT TLV- to use GRE encapsulation without UDP tunneling, e.g., the mobile
HEADER NOT SUPPORTED> has the (T) flag cleared. The mobile access access gateway is NOT behind a NAT, the mobile access gateway MUST
gateway may resend the Proxy Binding Update to negotiate different update the mobile node Binding Update List entry described in
tunneling options, e.g., using UDP based tunneling without GRE Section 4.1 by setting the GRE encapsulation enabled flag and the
encapsulation if possible or de-register the the mobile node mobility uplink and downlink GRE key fields. In this case, the mobile access
session. gateway MUST set the UDP based TLV-Header format flag to FALSE. A
Proxy Binding Acknowledgement message with status <GRE TUNNELING BUT
TLV-HEADER NOT SUPPORTED> has the (T) flag cleared. Alternatively,
the mobile access gateway may resend the Proxy Binding Update to
negotiate different tunneling options, e.g., using UDP based
tunneling without GRE encapsulation if possible or de-register 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 or IPv4- When the mobile access gateway is located in an IPv6-enabled or IPv4-
enabled network, it may be required to use vanilla GRE encapsulation enabled network, it may be required to use GRE encapsulation for
for tunneling IPv6 or IPv4 payload data packet to the local mobility tunneling IPv6 or IPv4 payload data packet to the local mobility
anchor. In this case and if the mobile access gateway has anchor. In this case and if the mobile access gateway has
successfully negotiated GRE encapsulation mode only or GRE successfully negotiated GRE encapsulation mode only or GRE
encapsulation and GRE Keys as described in this specification, the encapsulation and GRE Keys as described in this specification, the
mobile access gateway encapsulates or decapsulates IPv6-or-IPv4 mobile access gateway encapsulates or decapsulates IPv6-or-IPv4
payload packets following the rules described in [RFC5213] and payload packets following the rules described in [RFC5213] and
[ID-PMIP6-IPv4] while ensuring that the GRE header is present as [ID-PMIP6-IPv4] while ensuring that the GRE header is present as
shown in Figure 7. 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 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 mobile access gateway and the local mobility anchor and successfully
TLV-header format, the mobile access gateway MUST use UDP TLV-header negotiated GRE encapsulation and the TLV-header format, the mobile
tunneling format when sending an IPv6 or IPv4 payload packet to the access gateway MUST use UDP TLV-header tunneling format when sending
LMA according to the format described in Figure 5. The source and an IPv6 or IPv4 payload packet to the local mobility according to the
the destination of the IPv4 outer header are V4CoA and HA_V4ADDR, format described in Figure 5. The source and the destination of the
IPv4 outer header are mobile node IPv4 Proxy Care-of Address , IPv4-
Proxy-CoA, and the IPv4 Local Mobility Anchor Address, IPv4-LMAA,
respectively. In addition the source and the destination IP respectively. In addition the source and the destination IP
addresses of the IPv6-or-IPv4 payload data packet are V6/V4HoA and addresses of the IPv6-or-IPv4 payload data packet are the Mobile
V6/V4CN, respectively. Node's IPv6 or IPv4 Home Address, IPv6/IPv4-MN-HoA, and the IPv6 or
IPv4 Corresponding Node's Address, IPv6/IPv4-CN-Addr, respectively.
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
Binding Acknowledgement. Otherwise, the LMA MUST NOT set the TLV- Binding Acknowledgement. Otherwise, the local mobility anchor MUST
header Format (T) flag in the Proxy Binding Acknowledgement. NOT set the TLV-header Format (T) flag in the Proxy Binding
Acknowledgement.
If the local mobility anchor receives a Proxy Binding Update with the 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 and the local mobility anchor supports TLV-
tunneling and if Proxy Binding Update has been successfully header tunneling and the local mobility anchor sent a successful
processed, the LMA MUST send a successful Proxy Binding Proxy Binding Acknowledgement with the TLV-header Format (T) flag
Acknowledgement with the status code <GRE TUNNELING BUT TLV-HEADER set, the local mobility anchor MUST update the mobile node's Binding
NOT SUPPORTED>. This way, the local mobility anchor indicates to the Cache entry described in Section 5.1 by setting the GRE encapsulation
mobile access gateway that GRE encapsulation has been successfully enabled flag and update the uplink and downlink GRE key fields. In
negotiated BUT TLV-header UDP based tunneling format is not addition, the local mobility anchor MUST set the UDP based TLV-Header
supported. format flag.
If the local mobility anchor receives a Proxy Binding Update with the
GRE Key option and TLV-header Format (T) flag set and based on a
policy check, the local mobility anchor determines that GRE
encapsulation is required BUT the local mobility anchor does NOT
support TLV-header tunneling and if Proxy Binding Update has been
successfully processed, the local mobility anchor MUST send a
successful Proxy Binding Acknowledgement with the status code <GRE
TUNNELING BUT TLV-HEADER NOT SUPPORTED>. This way, the local
mobility anchor indicates to the mobile access gateway that GRE
encapsulation has been successfully negotiated BUT TLV-header UDP
based tunneling format is not supported. In this case, the local
mobility anchor MUST update the mobile node BCE described in
Section 5.1 by setting the GRE encapsulation enabled flag and update
the uplink and downlink GRE key fields. In this case, the local
mobility anchor MUST set the UDP based TLV-Header format flag to
FALSE.
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 may use vanilla GRE encapsulation for The local mobility anchor may use GRE encapsulation for tunneling
tunneling IPv6 or IPv4 payload data packet to the mobile access IPv6 or IPv4 payload data packet to the mobile access gateway. If
gateway. If the LMA has successfully negotiated GRE encapsulation the local mobility anchor has successfully negotiated GRE
with the MAG for a specific mobility session, the local mobility encapsulation with the mobile access gateway for a specific mobility
anchor encapsulates and decapsulates IPv6-or-IPv4 payload data session, the local mobility anchor encapsulates and decapsulates
packets following the rules described in [RFC5213] and IPv6-or-IPv4 payload data packets following the rules described in
[ID-PMIP6-IPv4] while ensuring that the GRE header is present as [RFC5213] and [ID-PMIP6-IPv4] while ensuring that the GRE header is
shown in Figure 7. present as shown in Figure 7.
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 tunneling format and mobility anchor follows the TLV-header UDP based tunneling format and
headers order as shown in Figure 5 to encapsulate IPv4 or IPv6 headers order as shown in Figure 5 to encapsulate IPv4 or IPv6
payload packets in IPv4 before sending the IPv4 packet to the mobile payload packets in IPv4 before sending the IPv4 packet to the mobile
access gateway. In this case, the source and the destination of the access gateway. In this case, the source and the destination of the
IPv4 outer header are HA_V4ADDR and V4CoA, respectively. In addition IPv4 outer header are IPv4-LMAA and IPv4-Proxy-CoA, respectively. In
the source and the destination IP addresses of the IPv6-or-IPv4 addition the source and the destination IP addresses of the IPv6-or-
payload data packet are V6/V4CN and V6/V4HoA, respectively. On the IPv4 payload data packet are IPv6/IPv4-CN-Addr and IPv6/IPv4-MN-HoA,
other hand, the local mobility anchor ensures the same TLV-header UDP respectively. On the other hand, the local mobility anchor ensures
based tunneling format and headers order when it decapsulates the same TLV-header UDP based tunneling format and headers order when
received IPv4 packets from the mobile access gateway for the same it decapsulates received IPv4 packets from the mobile access gateway
mobility session. for the same mobility session.
7.5. Mobile Node Operation
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
same numbering space as allocated for the other mobility options same numbering space as allocated for the other mobility options
defined in the Mobile IPv6 specification [RFC3775]. defined in the Mobile IPv6 specification [RFC3775].
This specification also defines three new Binding Acknowledgement This specification also defines three new Binding Acknowledgement
skipping to change at page 21, line 45 skipping to change at page 22, line 15
three codes be allocated with numeric values as specified in three codes be allocated with numeric values as specified in
Section 6.4 from the "Status Codes" registry of the Mobility IPv6 Section 6.4 from the "Status Codes" registry of the Mobility IPv6
Parameters located at Parameters located at
http://www.iana.org/assignments/mobility-parameters. http://www.iana.org/assignments/mobility-parameters.
9. Security Considerations 9. Security Considerations
The GRE Key Option, defined in this specification, that can be The GRE Key Option, defined in this specification, that can be
carried in Proxy Binding Update and Proxy Binding Acknowledgement carried in Proxy Binding Update and Proxy Binding Acknowledgement
messages, reveals the group affiliation of a mobile node identified messages, reveals the group affiliation of a mobile node identified
by its NAI or an IP address. It may help an attacker in targeting by its Network Access Identifier (NAI) or an IP address. It may help
flows belonging to a specific group. This vulnerability can be an attacker in targeting flows belonging to a specific group. This
prevented, by enabling confidentiality protection on the Proxy vulnerability can be prevented, by enabling confidentiality
Binding Update and Proxy Binding Acknowledgement messages where the protection on the Proxy Binding Update and Proxy Binding
presence of the NAI and GRE Key Options establish a mobile node's Acknowledgement messages where the presence of the NAI and GRE Key
relation to a specific group. This vulnerability can also be avoided Options establish a mobile node's relation to a specific group. This
by enabling confidentiality protection on all the tunneled data vulnerability can also be avoided by enabling confidentiality
packets between the mobile access gateway and the local mobility protection on all the tunneled data packets between the mobile access
anchor, for hiding all the markings. gateway and the local mobility anchor, for hiding all the markings.
In Proxy Mobile IPv6 [RFC5213], the use of IPsec [RFC4301] for In Proxy Mobile IPv6 [RFC5213], the use of IPsec [RFC4301] for
protecting a mobile node's data traffic is optional. Additionally, protecting a mobile node's data traffic is optional. Additionally,
Proxy Mobile IPv6 recommends the use of ESP in tunnel mode when using Proxy Mobile IPv6 recommends the use of Encapsulating Security
ESP in protecting the mobile node's data traffic. However, when GRE Payload (ESP) [RFC4303] in tunnel mode when using ESP in protecting
encapsulation is used, both IPsec tunnel mode and transport mode can the mobile node's data traffic. However, when GRE encapsulation is
be used to protect the GRE header. The IPsec traffic selectors will used, both IPsec tunnel mode and transport mode can be used to
contain the protocol number for GRE, and there is currently no protect the GRE header. The IPsec traffic selectors will contain the
mechanism to use the GRE key as a traffic selector. protocol number for GRE, and there is currently no mechanism to use
the GRE key as a traffic selector.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Alessio Casati, Barney Barnowski, The authors would like to thank Alessio Casati, Barney Barnowski,
Mark Grayson and Parviz Yegani for their input on the need for this Mark Grayson and Parviz Yegani for their input on the need for this
option. The authors would like to thank Charlie Perkins, Curtis option. The authors would like to thank Charlie Perkins, Curtis
Provost, Irfan Ali, Jouni Korhonen, Julien Laganier, Kuntal Provost, Irfan Ali, Jouni Korhonen, Julien Laganier, Kuntal
Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review
and comments. and comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[ID-DSMIP6]
Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", draft-ietf-mext-nemo-v4traversal-07 (work in
progress), December 2008.
[ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-11 (work in progress),
January 2009.
[ID-PMIP6-IPv4]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09
(work in progress), January 2009.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996. October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 23, line 28 skipping to change at page 23, line 33
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000. RFC 2890, September 2000.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[ID-PMIP6-IPv4]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-12
(work in progress), April 2009.
11.2. Informative References 11.2. Informative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-13 (work in progress),
April 2009.
Authors' Addresses Authors' Addresses
Ahmad Muhanna Ahmad Muhanna
Nortel Nortel
2221 Lakeside Blvd. 2221 Lakeside Blvd.
Richardson, TX 75082 Richardson, TX 75082
USA USA
Email: amuhanna@nortel.com Email: amuhanna@nortel.com
Mohamed Khalil Mohamed Khalil
Nortel Nortel
2221 Lakeside Blvd. 2221 Lakeside Blvd.
Richardson, TX 75082 Richardson, TX 75082
USA USA
Email: mkhalil@nortel.com Email: mkhalil@nortel.com
Sri Gundavelli Sri Gundavelli
Cisco Systems Cisco Systems
 End of changes. 68 change blocks. 
277 lines changed or deleted 347 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/