GRE Key Extension for Mobile IPv4Juniper Netowrks1194 North Mathilda Ave.SunnyvaleCalifornia94089U.S.A+1 408-759-1973pyegani@juniper.netCisco Systems Inc.170 West Tasman Dr.San JoseCalifornia95134U.S.A+1 408 525 1404gdommety@cisco.comBridgewater Systems Corporation303 Terry Fox DriveOttawaOntarioK2K 3J1Canada+1 613-591-6655avi@bridgewatersystems.comStarent Networks30 International PlaceTewksburyMA01876USA+1 214 550 1416kchowdhury@starentnetworks.comStarent Networks30 International PlaceTewksburyMA01876USA+1 978 851 1141jnavali@starentnetworks.comThe GRE specification contains a Key field, which MAY contain a
value that is used to identify a particular GRE data stream. This
specification defines a new Mobile IP extension that is used to
exchange the value to be used in the GRE Key field. This extension
further allows the Mobility Agents to setup the necessary protocol
interfaces prior to receiving the mobile's traffic. The new extension
option allows a foreign agent to request GRE tunneling without
disturbing the Home Agent behavior specified for Mobile Ipv4.
GRE tunneling provides an advantage that allows operator's private
home networks to be overlaid and allows the HA to provide overlapping
home addresses to different subscribers. When the tuple < Care of
Address, Home Address and Home Agent Address > is the same across
multiple subscriber sessions, GRE tunneling will provide a means for
the FA and HA to identify data streams for the individual sessions
based on the GRE key. In the absence of this key identifier, the data
streams cannot be distinguished from each other, a significant
drawback when using IP-in-IP tunneling.This document specifies a new extension for use by Foreign Agents
operating Mobile IP for IPv4. The new extension option allows a
foreign agent to request GRE tunneling without disturbing the
Home Agent behavior specified for Mobile IPv4 .
This extension contains the GRE key and other necessary information
required for establishing a GRE tunnel between the FA and the HA.GRE tunneling provides an advantage that allows operator's private
home networks to be overlaid and it allows the HA to provide
overlapping home addresses to different subscribers. When the tuple
< Care of Address, Home Address and Home Agent Address > is the same
across multiple subscriber sessions, GRE tunneling will provide a
means for the FA and the HA to identify data streams for the individual
sessions based on the GRE key. In the absence of this key identifier,
the data streams cannot be distinguished from each other, a significant
drawback when using IP-in-IP tunneling.The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
Other terminology is used as already defined in
.The format of the GRE-Key Extension conforms to the Extension format
specified for Mobile IPv4 [RFC3344]. This extension option is used by
the Foreign Agent to supply GRE key and other necessary information to
the Home Agent to establish a GRE tunnel between the FA and the HA.The FA MUST support IP-in-IP tunneling of datagrams for Mobile IPv4
. The FA may support GRE tunneling that can be
used, for example, to allow for overlapping private home IP addresses
[X.S0011-D]. If the FA is capable of supporting GRE encapsulation, it
should set the 'G' bit in the Flags field in the Agent Advertisement
message sent to the MN during the Mobile IP session establishment.If the MN does not set the 'G' bit, the FA MAY fall back to using
IP-in-IP encapsulation for the session per .If the MN does not set the 'G' bit, and the local policy allows the
FA to override the 'G' bit setting received from the MS, the FA MUST
include the GRE-Key Extension as defined in this memo in the
Registration Request message to request GRE encapsulation for the
session. If the FA does not support GRE encapsulation, the FA MUST reset the
'G' bit in the Agent Advertisement message. In this case, if the MN
sets the 'G' bit in the Registration Request message, the FA returns a
Registration Reply message to the MN with code 'Requested Encapsulation
Unavailable' (0x48) per .If the FA allows GRE encapsulation, and either the MN requested GRE
encapsulation or local policy dictates using GRE encapsulation for the
session, the FA MUST include the GRE Key in the GRE Key Extension in all
Mobile IP Registration Requests (including initial, renewal and
de-registration requests) before forwarding the request to the HA. The
FA may include a GRE key of value zero in the GRE Key Extension to signal
that the HA assign GRE keys in both directions. The GRE key assignment
in the FA and the HA is outside the scope of this memo.The GRE Key Extension SHALL follow the format defined in
. This extension SHALL be added after the
MN-HA and MN-FA Challenge and MN-AAA extensions (if any) and before the
FA-HA Auth extension (if any). The HA MUST follow the procedures specified in RFC 3344 in
processing this extension in Registration Request messages. If the HA
receives the GRE Key Extension in a Registration Request and does not
recognize GRE Key Extension, it MUST send an RRP with code
'Unknown Extension (0xY1)' per .If the HA receives the GRE Key Extension in a Registration Request
and recognizes the GRE Key Extension but is not configured to support
GRE encapsulation, it MUST send an RRP with code 'Requested Encapsulati
on Unavailable (0xYY)'.If the HA receives a Registration Request with the 'G' bit set but
without the GRE Key Extension, it SHALL send an RRP with code
'Poorly Formed Request (0xY2)'.If the HA receives a Registration Request with a GRE Key Extension
but without the 'G' bit set, the HA SHOULD treat this as if 'G' bit is
set in the Registration Request i.e., the presence of GRE Key Extension
indicates a request for GRE encapsulation.If the HA receives the GRE Key Extension in a Registration Request
and recognizes the GRE Key Extension as well as supports GRE
encapsulation, the following procedures should apply:The HA SHOULD accept the RRQ and send a RRP with code
'Accepted (0)'. The HA MUST assign a GRE key and include the GRE Key
Extension in the RRP before sending it to the FA. The HA MUST include
the GRE Key Extension in all RRPs in response to any RRQ that included
GRE Key Extension, when a GRE key is available for the registration.
If the HA receives the GRE Key Extension in the initial Registration Request
and recognizes the GRE Key Extension carrying a GRE key value of zero,
it SHOULD accept the RRQ and send a RRP with code 'Accepted (0)'. The HA
MUST assign GRE keys for both directions and include these keys in the GRE
Key Extension in the RRP before sending it to the FA. The HA MUST include
the GRE Key Extension in the RRP in response to the initial RRQ that included
GRE Key Extension, when a GRE key is available for the registration. If the MN is capable of supporting GRE encapsulation, it SHOULD set
the 'G' bit in the Flags field in the Registration Request per
.GRE tunneling support for Mobile IP will permit asymmetric GRE keying
i.e., the FA assigns a GRE key for use in encapsulated traffic and the
HA can assign its own GRE key. Once the GRE keys have been exchanged,
the FA uses the HA-assigned key in the encapsulating GRE header for
reverse tunneling and the HA uses the FA-assigned key in the
encapsulating GRE header. The format of the GRE Key Extension is as shown below. The GRE Key extension MAY be included in Registration Requests
,
whose 'G' bit is enabled. The GRE Key extension is used to inform the
recipient of the Mobile IP request of the value to be used in GRE's
Key field. The GRE Key extension defined in this memo is as defined in
. IANA should assign a value for this Extension.
This specification does not introduce any new security
considerations, beyond those described in Thanks to ...